L'architecture d'un projet d'intelligence artificielle : trois patterns et la discipline qui les rend durables

Note refondue le 25 mai 2026. Article initialement publié en mars 2026 — refonte intégrale.

L'architecture d'un projet d'intelligence artificielle désigne l'ensemble des choix techniques structurants : quel modèle est utilisé, sous quel mode d'accès, comment les données sont gérées, comment les composants sont orchestrés. Ces choix conditionnent durablement le coût, la performance et l'évolutivité du résultat. Un mauvais départ technique coûte des mois de retard et des dizaines de milliers de francs ; un bon départ ne se voit pas, parce qu'il permet l'évolution sereine du projet sur plusieurs années.

Cette note expose les trois patterns d'architecture qui structurent la pratique en 2026, qualifie les critères qui distinguent leur usage approprié, et identifie la discipline qui rend ces choix durables au-delà du démarrage initial.

Trois patterns d'architecture qui structurent la pratique

La diversité apparente des projets d'intelligence artificielle se ramène, en pratique, à trois patterns d'architecture fondamentaux. Comprendre ce qui distingue ces trois patterns, et savoir lequel correspond à un cas d'usage donné, constitue la décision technique la plus structurante d'un projet.

Le pattern API Wrapper : l'accès direct aux modèles via interface programmatique

Le pattern le plus simple consiste à appeler un modèle de langage via son interface programmatique, et à construire la logique métier de l'application autour de cet appel. Pas d'infrastructure dédiée à gérer, pas de matériel spécialisé à provisionner. Le coût opérationnel est proportionnel à l'usage effectif.

Ce pattern convient au prototypage rapide, aux volumes modérés, et aux cas d'usage qui ne demandent pas une connaissance fine de données spécifiques à l'entreprise : résumé de textes génériques, classification simple, génération de contenu standard. Une PME peut atteindre un prototype fonctionnel en quelques jours avec cette approche.

Sa limite principale tient à la dépendance à un fournisseur unique. Le marché des modèles évolue rapidement, et les arbitrages prix-performance se déplacent régulièrement. Construire dès le départ une couche d'abstraction qui isole la logique métier du fournisseur de modèle préserve la liberté de changer de fournisseur sans réécrire l'application. Cette discipline — souvent désignée par le terme Provider Pattern — n'est pas un luxe ; c'est une assurance opérationnelle dont le coût initial est marginal et dont la valeur se révèle lors du premier changement de fournisseur.

Le pattern RAG : ancrer les réponses dans les données propres à l'entreprise

Le pattern RAG — pour Retrieval-Augmented Generation — est devenu le standard pour les projets d'entreprise qui demandent une connaissance des données propres à l'organisation. Au lieu de tout injecter dans le prompt envoyé au modèle, on combine un moteur de recherche sémantique avec un modèle de langage.

Le fonctionnement se décompose en trois étapes. D'abord l'indexation : les documents de l'entreprise — manuels, procédures internes, base de connaissances, catalogue produit, corpus juridique — sont découpés en segments et convertis en représentations vectorielles qui capturent leur sens sémantique. Ensuite la recherche : quand un utilisateur pose une question, le système identifie les segments les plus pertinents par similarité vectorielle, plutôt que par simple correspondance de mots-clés. Enfin la génération : le modèle reçoit la question accompagnée des segments pertinents, et produit une réponse contextualisée qui peut citer ses sources.

Ce pattern répond au défi central des modèles de langage utilisés seuls : les hallucinations. En ancrant chaque réponse dans des documents vérifiés, le système reste factuel. Quand la base de connaissances ne contient pas la réponse à une question, le système peut le dire explicitement plutôt que d'inventer.

Sa qualité dépend cependant directement de la qualité des données indexées. Des documents obsolètes, mal structurés, contradictoires ou incomplets produisent des réponses médiocres, quel que soit le modèle utilisé. Le travail de préparation des données — souvent négligé dans le discours commercial autour des outils — représente, dans la pratique observée en cabinet sur les projets MCVA, une part substantielle de l'effort total — typiquement entre la moitié et les deux tiers sur les projets sérieux. Cette observation mérite d'être posée au cadrage, parce qu'elle modifie substantiellement l'estimation de l'effort.

Le pattern agents : déléguer l'exécution de tâches multi-étapes

Le pattern agents représente le niveau de complexité suivant. Un agent est un système alimenté par modèle capable d'utiliser des outils — recherche web, calculs, appels d'API, interrogations de bases de données — et de planifier une séquence d'actions pour accomplir une tâche complexe.

Ce pattern convient aux tâches qui nécessitent plusieurs étapes coordonnées : recherche d'information, analyse intermédiaire, décision sur la suite à donner, exécution d'une action dans un système métier. L'automatisation de workflows complexes — vérification d'un statut de commande dans un système de gestion existant suivie d'une mise à jour dans un autre, par exemple — constitue le cas d'usage typique.

L'avantage opérationnel est substantiel quand le pattern est approprié : automatisation de bout en bout de processus métier qui demandaient classiquement plusieurs interventions humaines. Sa limite tient à la complexité de mise en œuvre — le débogage d'un agent multi-étapes est exigeant — et au coût opérationnel élevé : un agent peut effectuer plusieurs dizaines d'appels au modèle pour traiter une seule tâche complexe. Ce pattern est à réserver aux cas d'usage à forte valeur ajoutée où la complexité justifie le coût d'exploitation et de maintenance.

La discipline structurante : la qualité des données prime sur le choix du modèle

L'erreur la plus fréquente observable sur les projets d'intelligence artificielle consiste à concentrer l'attention sur le choix du modèle, alors que la qualité des données détermine de manière disproportionnée la qualité du résultat final.

Trois observations soutiennent cette qualification.

D'abord, sur les projets qui s'appuient sur des données propres à l'entreprise — la majorité des projets sérieux — la différence de qualité entre les principaux modèles disponibles est relativement modeste comparée à la différence produite par la qualité des données indexées. Un système RAG nourri avec des documents propres et structurés sur un modèle de capacité moyenne produit régulièrement de meilleurs résultats qu'un système RAG nourri avec des documents désorganisés sur un modèle de pointe.

Ensuite, l'investissement dans la qualité des données présente un caractère cumulatif et durable. Les données nettoyées et structurées une fois servent à tous les usages ultérieurs. Le choix d'un modèle, en revanche, doit être reconsidéré régulièrement parce que le marché évolue. Investir l'effort dans les données plutôt que dans la sélection du modèle produit donc une valeur plus durable.

Enfin, la pratique observable montre que les projets qui échouent partagent une caractéristique commune : ils ont sous-estimé l'effort de préparation des données, et ils l'ont découvert trop tard. Les projets qui réussissent investissent dès le cadrage initial dans cette préparation, et ils accompagnent le déploiement de processus de maintenance des données qui préservent la qualité dans la durée.

Cinq erreurs récurrentes que la pratique observe

Au-delà du choix du pattern et de l'attention aux données, cinq erreurs récurrentes méritent d'être identifiées parce qu'elles produisent des coûts d'opportunité substantiels.

Commencer par l'entraînement complémentaire d'un modèle. L'entraînement complémentaire — souvent désigné par le terme fine-tuning — est rarement nécessaire en première intention. Dans la grande majorité des cas, un système RAG avec des prompts bien construits produit des résultats équivalents pour une fraction du coût et de l'effort. L'entraînement complémentaire est pertinent dans des situations spécifiques où le modèle doit adopter un style très particulier ou maîtriser un vocabulaire technique que le RAG ne couvre pas correctement. Avant d'investir dans cette voie, il est généralement productif de pousser plus loin l'optimisation du RAG.

Ignorer la qualité des données. Le point a été développé plus haut, mais il mérite d'être rappelé parce qu'il constitue probablement l'erreur la plus structurante.

Négliger l'évaluation systématique. Sans métriques de qualité — pertinence, fidélité aux sources, complétude — il est impossible de mesurer les progrès objectivement. Mettre en place un cadre d'évaluation dès le démarrage du projet, avec un jeu de référence de quelques dizaines de questions-réponses validées humainement, constitue l'investissement opérationnel dont le rendement est le plus élevé.

Sous-estimer les coûts opérationnels en production. Un prototype qui consomme un budget modéré en phase exploratoire peut atteindre un budget substantiellement plus important une fois passé en production réelle. Le calcul prévisionnel basé sur le nombre d'utilisateurs attendus, la fréquence d'utilisation et la taille moyenne des requêtes mérite d'être conduit au cadrage, plutôt que découvert en exploitation.

Construire un système monolithique. Un système qui mélange dans un seul bloc indissociable le moteur de recherche, le modèle de langage, le cache, l'interface utilisateur et la couche d'évaluation est difficile à faire évoluer et à déboguer. Une architecture modulaire, où chaque composant est indépendant, permet de remplacer un élément sans toucher aux autres. Cette modularité ne demande pas un effort substantiel au démarrage, mais elle préserve l'évolutivité du système sur la durée.

La stratégie progressive recommandée pour une PME

Pour une PME suisse qui démarre un projet d'intelligence artificielle, une approche progressive distingue les projets qui aboutissent de ceux qui s'enlisent.

La phase exploratoire d'abord, conduite avec un pattern API Wrapper sur un cas d'usage précis et mesurable. Cette phase, qui se déroule typiquement sur quelques semaines, valide que le concept tient debout dans le contexte spécifique de l'entreprise. Sa modestie est sa force : un investissement contenu, un risque limité, des apprentissages immédiats.

Le prototype enrichi ensuite, généralement avec un pattern RAG sur les données propres à l'entreprise, accompagné d'une évaluation systématique de la qualité et de premiers tests utilisateurs. Cette phase, qui se déroule sur quelques mois, ajuste le système aux conditions réelles d'usage et identifie les ajustements nécessaires avant la mise en production.

La mise en production avec monitoring complète la séquence. Cette phase déploie le système dans son contexte d'usage cible, avec les processus de feedback utilisateur, d'amélioration continue des prompts et de maintenance des données qui préservent la qualité dans la durée.

L'évaluation d'un éventuel entraînement complémentaire de modèle, ou de l'ajout d'agents pour automatiser des workflows complexes, intervient seulement après cette mise en production, sur la base d'observations réelles plutôt que d'hypothèses. Cette discipline d'attente distingue les projets qui consolident une valeur opérationnelle de ceux qui empilent des couches de complexité sans bénéfice tangible.

La souveraineté des données traitées

Pour les projets qui touchent des données soumises à la Loi fédérale sur la protection des données^[1] ou à des obligations sectorielles spécifiques, trois approches structurent la pratique, par ordre de contrainte croissante.

Les engagements contractuels de non-rétention d'abord, négociables avec les principaux fournisseurs de modèles pour leurs offres entreprise. Cette approche convient à la majorité des cas où les données sont sensibles sans être stratégiquement critiques.

L'hébergement sur infrastructure européenne ou suisse ensuite, qui garantit que les données ne quittent pas la juridiction concernée. Cette approche convient aux contextes où la localisation est une exigence explicite, soit réglementaire soit contractuelle.

Le déploiement sur infrastructure contrôlée complète la liste, généralement avec des modèles ouverts. Cette approche garantit que les données restent intégralement sur l'infrastructure de l'entreprise, au prix d'une compétence technique interne et d'investissements matériels qui peuvent être substantiels.

Pour les entreprises soumises à des réglementations sectorielles strictes — secteur financier, santé, administration publique — une analyse de risque formelle conduite au cadrage initial du projet évite des arbitrages coûteux à mi-parcours.

La discipline qui distingue le sérieux

Le choix d'une architecture pour un projet d'intelligence artificielle n'est pas une question d'expertise pointue inaccessible aux décideurs non techniques. C'est une question de discipline méthodique : poser le pattern approprié pour le cas d'usage, investir dans la qualité des données avant dans le choix du modèle, construire dès le départ les conditions d'évolutivité du système, traiter explicitement la question de la souveraineté plutôt que l'éluder.

Cette discipline distingue, là encore, les projets qui produisent une valeur durable de ceux qui consomment du budget sans transformer effectivement le fonctionnement de l'organisation. Elle ne demande pas de génie technique particulier. Elle demande une attention soutenue à la rigueur professionnelle des arbitrages initiaux.

Sur le pattern RAG en particulier, et sur les architectures conversationnelles qui s'en servent comme socle, voir aussi la note Les chatbots alimentés par modèles génératifs : de la FAQ scriptée aux agents qui agissent.

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 de MCVA Consulting SA, cabinet suisse de conseil stratégique en intelligence artificielle, basé en Valais.