Projet IA bien construit : les trois patterns qui tiennent

Un projet IA bien construit se reconnaît à trois choix posés avant la première ligne de code : un pattern d'architecture adapté au besoin — appel direct au modèle, RAG ou agents —, un investissement dans la qualité des données supérieur à celui consacré au choix du modèle, et une progression par étapes qui valide avant d'industrialiser. Un mauvais départ coûte des mois de retard et des dizaines de milliers de francs. Un bon départ ne se voit pas : le projet évolue sans drame pendant des années.

Trois patterns couvrent l'essentiel des projets

La diversité apparente des projets d'IA se ramène, en pratique, à peu de choses. En 2026, trois patterns d'architecture couvrent l'essentiel des projets IA d'entreprise : l'appel direct à un modèle via API, le RAG qui ancre les réponses dans les documents internes, et les agents qui exécutent des tâches multi-étapes. Identifier celui qui correspond à votre cas d'usage est la décision technique la plus structurante du cadrage.

L'appel direct via API est le pattern le plus simple : le modèle est interrogé par son interface programmatique, et la logique métier se construit autour. Aucune infrastructure dédiée, un coût proportionnel à l'usage, un prototype fonctionnel en quelques jours. Il convient aux volumes modérés et aux tâches génériques — résumé, classification, génération de contenu standard. Sa faiblesse : la dépendance à un fournisseur unique, sur un marché où les rapports prix-performance bougent sans cesse. La parade est connue et peu coûteuse — une couche d'abstraction qui isole la logique métier du fournisseur, pour pouvoir en changer sans réécrire l'application. Cette précaution paraît superflue le premier mois ; elle vaut de l'or au premier changement de modèle.

Le RAG — Retrieval-Augmented Generation — est devenu le standard dès que le système doit connaître vos données. Les documents de l'entreprise sont indexés sous forme vectorielle ; à chaque question, les segments les plus pertinents sont retrouvés et fournis au modèle, qui répond en s'appuyant dessus, sources citables à l'appui. C'est la réponse structurelle aux hallucinations : ancré dans des documents vérifiés, le système reste factuel — et peut admettre qu'il ne sait pas. J'en détaille la mécanique et les usages conversationnels dans un chatbot peut-il vraiment servir vos clients ?.

Les agents forment le niveau de complexité suivant : un système capable d'utiliser des outils — recherche, calculs, appels d'API, bases de données — et de planifier une séquence d'actions. C'est le pattern des workflows multi-étapes : vérifier un statut dans un système, décider, mettre à jour un autre système. Sa puissance a deux contreparties : un débogage exigeant, et un coût d'exploitation élevé — plusieurs dizaines d'appels au modèle pour une seule tâche. Je le réserve aux cas où la valeur automatisée justifie clairement cette facture.

Pourquoi vos données comptent plus que le modèle

L'erreur la plus répandue consiste à concentrer l'attention sur le choix du modèle — quel fournisseur, quelle version, quel benchmark — alors que la qualité des données détermine de façon disproportionnée la qualité du résultat.

Trois raisonnements soutiennent cette hiérarchie. D'abord, sur les projets ancrés dans des données d'entreprise — la majorité des projets sérieux —, l'écart entre les principaux modèles du marché est modeste comparé à l'écart que produit l'état des documents indexés : une base propre sur un modèle moyen bat régulièrement une base désorganisée sur un modèle de pointe. Ensuite, l'investissement dans les données est cumulatif : des documents nettoyés et structurés servent tous les usages ultérieurs, quand le choix d'un modèle doit être reconsidéré à chaque évolution du marché. Enfin, les projets qui s'enlisent partagent presque toujours le même trait — un effort de préparation des données sous-estimé, découvert trop tard.

FiscalDoc me l'a rappelé à petite échelle. La valeur de cette application locale ne vient pas du modèle qui tourne dessous : elle vient de la structure — catégories fiscales suisses définies proprement, convention de nommage stricte, base indexée pour la recherche. Le modèle est interchangeable. La structure, elle, est l'actif.

Les cinq erreurs qui coûtent le plus

Certaines erreurs reviennent avec une régularité qui mérite une liste — la voici, par ordre décroissant de dégâts :

1. Commencer par le fine-tuning. L'entraînement complémentaire d'un modèle est rarement nécessaire en première intention : un RAG bien construit produit des résultats équivalents pour une fraction du coût. Il ne se justifie que pour un style très particulier ou un vocabulaire que le RAG ne couvre pas.
2. Négliger les données. Le point précédent en a montré le mécanisme ; c'est l'erreur la plus structurante.
3. Se passer d'évaluation systématique. Sans jeu de référence — quelques dizaines de questions-réponses validées humainement — impossible de mesurer un progrès. C'est l'investissement au meilleur rendement de tout le projet.
4. Sous-estimer les coûts de production. Un prototype économe peut devenir coûteux une fois exposé à de vrais utilisateurs ; le calcul prévisionnel — utilisateurs, fréquence, taille des requêtes — se fait au cadrage, pas à la première facture.
5. Construire un monolithe. Recherche, modèle, cache, interface et évaluation soudés en un bloc rendent toute évolution périlleuse. Une architecture modulaire coûte peu au départ et préserve la capacité de remplacer un composant sans toucher aux autres.

Par où commencer ? La progression qui aboutit

Pour une PME suisse, la différence entre les projets qui aboutissent et ceux qui s'enlisent tient largement au séquencement. La phase exploratoire d'abord : un appel direct au modèle, un cas d'usage précis et mesurable, quelques semaines. Sa modestie est sa force — investissement contenu, apprentissages immédiats, droit à l'erreur réel. Le prototype enrichi ensuite : un RAG sur vos données, une évaluation systématique, de premiers utilisateurs internes, sur quelques mois. La mise en production enfin, avec ce qui la rend durable : retour utilisateur organisé, amélioration continue des prompts, maintenance de la base documentaire.

Les agents et l'éventuel fine-tuning viennent après la mise en production, sur la base d'observations réelles — jamais d'hypothèses. Cette discipline d'attente sépare les projets qui consolident de la valeur de ceux qui empilent de la complexité. C'est la progression que j'applique dans mes solutions sur-mesure, et elle vaut quel que soit le prestataire : un projet qui prétend sauter la phase exploratoire mérite votre méfiance.

Où vont vos données ? Trois niveaux de souveraineté

Dès que le projet touche des données couvertes par la LPD^[1] ou des obligations sectorielles, la question de la localisation se traite au cadrage. Trois approches structurent la pratique, par contrainte croissante. Les engagements contractuels de non-rétention, négociables avec les grands fournisseurs pour leurs offres entreprise, couvrent la majorité des cas où les données sont sensibles sans être critiques. L'hébergement sur infrastructure suisse ou européenne garantit que les données ne quittent pas la juridiction — la voie des exigences réglementaires ou contractuelles explicites. Le déploiement de modèles ouverts sur infrastructure contrôlée, enfin, garde tout à l'intérieur de l'entreprise, au prix d'une compétence technique et d'un investissement matériel réels — FiscalDoc en est la preuve d'existence à l'échelle d'une personne : un modèle open source sur mon Mac, zéro donnée qui sort.

Pour les secteurs strictement réglementés — finance, santé, administration —, une analyse de risque formelle au cadrage évite les arbitrages coûteux à mi-parcours.

Au fond, une architecture IA saine ne relève pas d'une expertise inaccessible aux décideurs non techniques ; elle relève d'une discipline : le bon pattern pour le bon besoin, les données avant le modèle, la modularité avant la vitesse, la souveraineté posée explicitement. Cette grille s'inscrit dans la démarche d'ensemble que je décris dans Que doit faire une PME suisse face à l'IA en 2026 ? — et elle se vérifie projet après projet dans mes accompagnements.

Ce qu'il faut retenir

— Trois patterns couvrent l'essentiel des projets IA en 2026 : appel direct via API, RAG ancré dans vos documents, agents multi-étapes — le cadrage commence par ce choix. — La qualité des données pèse plus que le choix du modèle : une base propre sur un modèle moyen bat une base désorganisée sur un modèle de pointe. — Progresser par étapes — exploration, prototype évalué, production monitorée — et réserver agents et fine-tuning à l'après-production.

FAQ

Faut-il entraîner un modèle sur les données de mon entreprise ? Rarement, et jamais en première intention. Un RAG bien construit — vos documents indexés, retrouvés et fournis au modèle à chaque question — produit des résultats équivalents pour une fraction du coût et de l'effort. Le fine-tuning ne se justifie que pour un style ou un vocabulaire très spécifiques, après avoir poussé le RAG à ses limites.

Quel modèle choisir pour démarrer ? Moins décisif qu'on ne le pense. L'écart entre les principaux modèles du marché est modeste comparé à l'effet de la qualité de vos données. Le choix raisonnable : un modèle courant, derrière une couche d'abstraction qui permet d'en changer sans réécrire l'application — le marché bouge trop vite pour s'enfermer.

Combien de temps avant un premier résultat utile ? Une phase exploratoire bien cadrée — un cas d'usage précis, un appel direct au modèle — livre ses enseignements en quelques semaines. Le prototype ancré dans vos données demande ensuite quelques mois, évaluation comprise. Se méfier des promesses de déploiement complet en quinze jours comme des projets qui planifient dix-huit mois avant le premier test utilisateur.

Comment garantir que mes données restent en Suisse ? Trois niveaux existent, par contrainte croissante : engagements contractuels de non-rétention avec le fournisseur du modèle, hébergement sur infrastructure suisse ou européenne, ou déploiement d'un modèle ouvert sur votre propre infrastructure. Le bon niveau dépend de la sensibilité réelle des données traitées — c'est une décision de cadrage, pas un détail technique.

Un projet IA se dessine dans votre entreprise ? Le Diagnostic d'Usage IA : soixante minutes pour poser vos flux réels, identifier ce qui mérite du sur-mesure, ce qui reste en SaaS, et ce qui n'a pas besoin d'IA du tout. Réserver un diagnostic

Sources

[1] Loi fédérale sur la protection des données (LPD), révision du 25 septembre 2020, entrée en vigueur le 1ᵉʳ septembre 2023. www.fedlex.admin.ch/eli/cc/2022/491/fr [↩]

Jérôme Deshaie est CEO et fondateur de MCVA Consulting SA, agence augmentée basée en Valais. Quinze ans au service de grandes marques internationales, désormais en direct pour les PME suisses. Parcours.