La plupart des organisations qui se lancent dans les agents IA oscillent entre deux échecs. D’un côté, un terrain de jeu sans règles où chacun bricole son agent, produit des démos convaincantes, et n’en met jamais aucune en production. De l’autre, une gouvernance descendante si stricte qu’elle étouffe l’expérimentation avant qu’un seul cas d’usage n’émerge. Les deux mènent au même résultat : beaucoup d’activité, peu de valeur.
L’AI Platform Engineering répond à ce dilemme non pas par un processus unique, mais par trois régimes qui cohabitent : l’exploration, la capitalisation et l’industrialisation. Chacun a ses propres règles, et le passage de l’un à l’autre est explicite. C’est cette méthodologie, plus que n’importe quel framework, qui sépare une collection de prototypes d’un parc d’agents réellement en production.
Deux échecs symétriques
Le premier échec est celui du playground laissé à lui-même. On donne à des équipes un accès à des modèles et à un cadre d’agents, l’expérimentation explose, et des dizaines de démos apparaissent. Aucune ne franchit l’étape de la production, parce que personne n’a défini ce que « prêt pour la production » veut dire, ni qui en porte la responsabilité.
Le second échec est l’excès inverse. Pour éviter le désordre, on impose dès le premier jour un processus de validation lourd, des revues d’architecture et des comités. Résultat : plus personne n’ose tester une idée, et les rares projets qui survivent arrivent trop tard, déconnectés du besoin réel.
Notre constat est simple : ces deux régimes sont nécessaires, mais à des moments différents. L’erreur est de vouloir n’en appliquer qu’un seul à tout le cycle de vie d’un agent.
Trois régimes qui cohabitent
Exploration : un playground sans friction
Le premier régime est un espace où tester coûte presque rien. Un ingénieur doit pouvoir brancher un agent sur des données réelles en lecture seule, essayer un prompt, un outil, une chaîne de raisonnement, et voir le résultat en quelques minutes. Pas de ticket, pas de revue préalable. La seule règle est celle du bac à sable : accès restreint, aucune action irréversible, traçabilité par défaut.
Ce qui compte à ce stade n’est pas la robustesse, mais la vitesse d’apprentissage. On cherche à répondre à une seule question : ce cas d’usage mérite-t-il qu’on aille plus loin ? La plupart des idées mourront ici, et c’est le but. Un playground qui ne produit aucun abandon ne sert à rien.
Capitalisation : transformer un essai en actif partagé
Un agent qui marche sur le poste d’un ingénieur n’a aucune valeur tant qu’il y reste. Le deuxième régime consiste à extraire, dans une exploration réussie, ce qui est réutilisable : un prompt éprouvé, un connecteur vers un outil métier, un jeu d’exemples, une façon de découper un problème.
Concrètement, cela suppose un endroit où ces briques sont documentées, versionnées et présentées aux autres équipes. Cela suppose aussi de former : montrer comment un cas d’usage a été résolu, pour que le suivant ne reparte pas de zéro. Sans ce régime intermédiaire, chaque équipe réinvente les mêmes connecteurs et les mêmes garde-fous, et l’organisation n’apprend jamais à l’échelle.
Industrialisation : des critères de passage explicites
Le troisième régime est le plus strict, et il doit l’être. Faire passer un agent en production, surtout quand il agit et ne se contente pas de répondre, engage la responsabilité de l’organisation. Ce passage ne se décide pas au ressenti après une bonne démo. Il repose sur des critères vérifiables : le cas est-il assez récurrent pour justifier l’effort, son déroulé est-il déterministe, ses actions sont-elles réversibles, chaque étape est-elle observable, et l’équipe qui exploitera l’agent est-elle d’accord pour l’exécuter ?
Tant que ces conditions ne sont pas réunies, l’agent reste en capitalisation ou en exploration. Cette exigence n’est pas un frein : c’est ce qui rend l’autonomie acceptable, parce qu’elle reste cantonnée aux cas où elle ne présente pas de risque.
Le vrai sujet : le passage d’un régime à l’autre
La difficulté d’une méthodologie IA en production ne tient pas à chacun de ces régimes pris isolément, mais à leurs transitions. Un playground sans porte de sortie vers la capitalisation produit des démos orphelines. Une industrialisation sans playground en amont produit des agents rigides, conçus loin du terrain.
Nous rendons donc chaque passage explicite. Aller de l’exploration à la capitalisation répond à une question de valeur : d’autres équipes ont-elles le même besoin ? Aller de la capitalisation à l’industrialisation demande des preuves, pas des impressions : un comportement mesuré sur des cas réels, des tests de non-régression, l’accord de l’équipe exploitante. C’est un sujet à part entière, que nous traiterons dans un prochain article consacré à l’évaluation d’un agent avant sa mise en production.
Ce découpage explique aussi pourquoi le choix d’outillage vient après, pas avant. Le socle d’exécution managé sur AWS que nous utilisons pour faire tourner ces agents ne remplace pas la méthode : il la sert. Il rend l’industrialisation moins coûteuse, sans décider à votre place de ce qui mérite d’être industrialisé.
Ce que cette méthodologie change
Adopter l’AI Platform Engineering, ce n’est pas ajouter un outil de plus. C’est accepter que trois régimes coexistent en permanence, et que la valeur naît de leur articulation. L’exploration alimente la capitalisation, qui alimente l’industrialisation, qui à son tour révèle de nouveaux besoins à explorer.
Pour une DSI, le premier pas concret tient en trois questions. Disposons-nous d’un playground où un ingénieur peut tester un agent sur des données réelles sans demander la permission ? Avons-nous un endroit où les explorations réussies deviennent des briques partagées ? Et avons-nous écrit noir sur blanc les critères qu’un agent doit remplir pour passer en production ? Si l’une des réponses est non, c’est là que se situe le prochain chantier.
C’est aussi cette logique qui permet de franchir l’écart entre la démo et la production de façon répétable, cas d’usage après cas d’usage, au lieu de le refaire à la main à chaque fois.
Vous structurez une pratique d’agents IA et cherchez à la faire passer à l’échelle ? Parlons-en.