Lors d’une récente réunion de travail avec le directeur technique (CTO) d’une grande entreprise, nous avons discuté d’une question que je considère comme l’un des plus grands défis stratégiques actuels : comment éviter que les agents d’IA d’aujourd’hui ne deviennent la dette technique de demain ?
La conversation m’a rappelé un problème que l’ingénierie logicielle connaît et combat depuis des décennies. Chaque nouvelle vague technologique commence de manière simple, séduisante et agile. Un premier système résout un problème précis. Puis vient le second. Encore un autre. De petites personnalisations, des intégrations héritées, des exceptions de parcours et des règles métier complexes s’ajoutent progressivement. Après quelques années, le système devient une boîte noire : peu de personnes sont capables d’expliquer son fonctionnement dans son ensemble, et la crainte de le modifier freine l’innovation.
Il existe de forts indices que tout ou partie de ce cycle pourrait se répéter avec les agents d’IA, bien que dotés de caractéristiques propres et à une vitesse nettement plus élevée.
Aujourd’hui, la barrière d’entrée a été drastiquement réduite. Les plateformes low-code/no-code, les cadres modulaires et les outils de vibe coding permettent de créer des agents fonctionnels en quelques heures. Le principal risque est de confondre la facilité de construire un prototype avec la capacité de développer une architecture durable.
Ce ne sont pas les mêmes choses. Dans les environnements d’entreprise, de nombreux agents cessent d’être des applications isolées et en viennent à dépendre d’une combinaison de LLM, bases RAG, mémoires, orchestrateurs, API, systèmes hérités, politiques d’accès et intégrations critiques. À mesure que des dizaines, voire des centaines de ces agents interagissent, le nombre d’agents augmente non seulement, mais aussi la quantité de dépendances, d’états partagés, de flux de communication et de points potentiels de défaillance. Par conséquent, la complexité a tendance à croître de manière non linéaire.
Le défi augmente parce que, contrairement aux vagues technologiques précédentes de démocratisation, pratiquement tous les domaines d’activité peuvent désormais bâtir des agents. Cela accélère l’innovation, mais réduit aussi l’une des barrières traditionnelles de la gouvernance exercée par les équipes centrales de TI.
Sans directives communes, le risque de prolifération de silos d’agents augmente : agents développés avec des cadres différents, mémoires incompatibles, mécanismes d’authentification propres et intégrations peu standardisées.
Au début, cette autonomie est perçue comme de l’agilité. Avec le temps, elle peut évoluer vers une fragmentation architecturale. Chaque agent conserve son propre contexte. Chaque équipe définit des métriques différentes. Chaque projet choisit des modèles et des outils selon ses propres critères.
De plus, l’écosystème évolue rapidement. Des cadres peuvent devenir obsolètes en quelques mois, des modèles sont retirés ou remplacés par les fournisseurs, les API évoluent continuellement et de nouveaux standards apparaissent à un rythme bien plus rapide que celui observé dans l’ingénierie logicielle traditionnelle.
S’il n’existe pas une architecture adéquate, les conséquences ont tendance à inclure des coûts croissants et peu prévisibles, un comportement en production incohérent, des difficultés d’audit, une faible réutilisation des composants et une augmentation continue de la dette technique.
Il existe encore un facteur aggravant important. Les composants centraux de ces systèmes sont probabilistes. Leur comportement peut changer même sans modification du code de l’application, que ce soit par la mise à jour du modèle effectuée par le fournisseur, l’évolution de la base de connaissances, l’incorporation de nouvelles mémoires ou les changements dans les outils utilisés.
Cela rend insuffisant le modèle traditionnel de développement reposant sur la simple construction, le test, le déploiement et le maintien de versions relativement stables. Les systèmes agents exigent une surveillance continue, une évaluation permanente, des garde-fous, de l’observabilité, une réévaluation des invites (prompts), une mise à jour des bases de connaissance et une recalibration fréquente.
Un autre aspect que je considère fondamental est d’éviter d’accoupler la logique métier au modèle. Une architecture mature traite le LLM comme un composant remplaçable, et non comme le cœur de l’application. Lorsque les règles métier sont intégrées dans des invites spécifiques ou dans des fonctionnalités propriétaires d’un seul fournisseur, on crée une nouvelle forme de dette technique, à savoir l’emprisonnement technologique (vendor lock-in).
C’est précisément ce point qui est apparu comme la conclusion principale de notre discussion. Le défi ne sera pas de construire des agents de plus en plus « intelligents », mais des plateformes capables de les soutenir sur le long terme.
Concrètement, cela signifie investir dans cinq piliers :
1) Plateformisation : créer une plateforme commune de services pour les agents.
2) Standardisation : unifier l’identité, la gouvernance du contexte, la mémoire et l’accès aux modèles.
3) Industrialisation : établir des pratiques de LLMOps pour transformer des prototypes en solutions d’entreprise.
4) Observabilité : surveiller en continu les coûts, les performances, le comportement et la qualité des réponses.
5) Refactorisation continue : traiter les prompts, les flux, les outils et les bases de connaissance comme des actifs devant évoluer en permanence.
Ainsi, la gouvernance de l’IA cesse d’être une simple préoccupation opérationnelle et devient une discipline d’architecture d’entreprise.
En fin de compte, nous réaffirmons les principes classiques de la bonne ingénierie logicielle, tels que le faible couplage, la forte cohésion, l’abstraction, la modularité et la séparation des responsabilités. Lorsque les agents passent des démonstrations à l’exécution de processus critiques, ces principes redeviennent déterminants.
La question la plus importante pour évaluer la maturité d’une architecture d’IA est assez simple : « Si demain je dois remplacer le modèle, le cadre ou même le fournisseur d’IA, dans quelle mesure mon application continuera-t-elle à fonctionner sans grands changements ? »
À mon avis, l’avantage concurrentiel de l’IA d’entreprise ne résidera pas dans le fait de construire le plus grand nombre d’agents dans le moindre délai. Il résidera dans la capacité à bâtir une architecture de plateforme résiliente, observable et évolutive, capable d’empêcher que les agents innovants d’aujourd’hui ne deviennent la principale dette technique de l’organisation demain.
