Pionnier DevOps met en garde : l'adoption d'agents IA exige des changements au niveau du système, et non seulement des outils

Ne corrigez plus le code produit par l'Agent ; corrigez le système qui produit ce code.

Auteur et source de l'article : InfoQ

Si un développeur ne parvient pas à utiliser correctement un Agent, le problème ne réside probablement pas dans le développeur, mais dans le fait que l'entreprise n'a pas mis en place un système fonctionnel pour l'Agent.

La plupart des entreprises prétendent effectuer une transformation par l'IA, mais se contentent d'acheter des outils comme Cursor ou Claude Code pour leurs développeurs, d'organiser quelques formations, puis de laisser tout le monde explorer par lui-même. Si les agents n'ont pas de bons résultats, la faute retombe sur les utilisateurs.

Mais Patrick Debois, l'auteur du terme DevOps, estime : « Les développeurs doivent effectuer un changement de mentalité important : lorsque l'Agent n'accomplit pas la tâche comme prévu, ne modifiez pas le code qu'il a généré, mais améliorez l'ensemble du système, et non seulement le Prompt. »

Pour Debois, il s'agit d'un changement inévitable lorsqu'on passe de systèmes déterministes à des systèmes non déterministes, probabilistes et des flux de travail. Il ne concerne pas seulement la technologie, mais redéfinit également la manière dont les développeurs, les équipes et l'ensemble de l'organisation travaillent. Toutefois, ce changement ne peut pas être réalisé par un seul ingénieur ni se limiter à une seule équipe. Comme le DevOps, il ne devient véritablement efficace qu'à l'échelle.

Le cœur du problème n'est pas seulement de savoir si les développeurs utiliseront les agents, mais si l'entreprise peut réorganiser ses équipes, sa plateforme et ses modes de collaboration autour des agents.

Les points clés sont les suivants :

• Ne corrigez plus le code produit par l'Agent ; corrigez le système qui produit ce code.
• Si quelqu’un dans votre équipe utilise encore cette approche sauvage de « YOLO » pour faire du vibe coding, vous devez l’arrêter immédiatement. Les pratiques d’ingénierie sont essentielles non seulement pour maintenir votre système, mais aussi pour permettre à l’Agent de s’améliorer continuellement.
• La fabrique sombre n'est peut-être pas entièrement sombre, mais conserve un léger éclat (dim factory), ce qui signifie que vous devez décider du niveau de risque à assumer pour chaque fonctionnalité, car toutes ne sont pas adaptées à une autonomie totale.
• Ce que vous cherchez, c’est quelqu’un qui maîtrise l’IA à un niveau extrême, possède une solide expertise technique et est prêt à partager et collaborer.
• Votre avantage concurrentiel réside dans la capture des connaissances accumulées, ces contextes métier que vous intégrez actuellement dans Skill, Context et même les contraintes de Harness.

En 2009, beaucoup de gens m'ont dit que l'idée de livraison continue était folle.

Remarque du traducteur : En 2009, l'industrie adoptait couramment un modèle de déploiement majeur tous les mois, avec l'idée reçue que plus les publications étaient fréquentes, plus le risque était élevé. De plus, les barrières entre le développement et les opérations étaient étanches, les infrastructures automatisées telles que les conteneurs et le cloud n'étaient pas encore matures, et il manquait des outils de pipeline standardisés. Les mécanismes traditionnels de test et d'approbation des changements visaient à éliminer autant que possible les défauts avant le déploiement, tandis que la livraison continue introduisait une approche fondée sur des mises à jour fréquentes, incrémentales et toujours prêtes à être déployées, bouleversant ainsi les perceptions établies sur les risques et la gestion des processus de déploiement logiciel. Par conséquent, pour la plupart des entreprises, cela semblait presque impossible et extrêmement fou.

Et maintenant, Dark Factory rencontre à nouveau exactement les mêmes obstacles.

Note de traduction : L'usine sombre désigne un modèle de production logicielle autonome piloté par l'IA, où les humains ne fournissent que le SPEC, et l'IA effectue automatiquement le codage, les tests et le déploiement, sans nécessiter d'examen ligne par ligne par un humain, contrairement aux usines logicielles traditionnelles qui exigent une participation importante d'ingénieurs.

J'entends répétitivement la même phrase dans divers contextes : « Cela ne fonctionne pas chez nous. » Mais le message réel derrière cette phrase n'est pas que la technologie est inefficace, c'est que « nous ne sommes pas prêts ». Ce n'est pas qu'ils ne veulent pas mettre en œuvre cela, c'est que la structure actuelle de l'organisation ne permet pas de soutenir ce modèle.

Beaucoup de gens parlent aujourd’hui de comment optimiser les agents avec des boucles, ou de comment construire des harnesses — ce sont d’excellentes choses. Mais ce que je veux dire, c’est que nous atteindrons tous un jour ce niveau technologique, et un jour, ces outils deviendront des produits standardisés, voire proposés comme services par des laboratoires de pointe. À ce moment-là, il n’y aura plus de barrières technologiques. La véritable différenciation réside dans la manière dont votre organisation va repenser ses modes de collaboration autour de ces outils.

Donc, je suppose que nous nous dirigeons tous vers l’usine sombre. Ce que j’ai observé chez Tessl et d’autres entreprises, c’est que lorsque les gens commencent à adopter ces technologies, la dynamique de collaboration change radicalement. Si vous connaissez la loi de Conway, vous savez qu’il existe une relation de co-formulation entre la structure organisationnelle et les outils — la façon dont vous organisez vos personnes détermine le type de système que vous créez. Mais aujourd’hui, je ne veux pas parler de comment rendre vos agents meilleurs ; je veux parler de la manière dont cela modifie votre dynamique d’équipe, votre plateforme et votre organisation dans son ensemble.

Je suppose que la plupart d’entre vous travaillent au sein d’une équipe, et non en solitaire ; la collaboration d’équipe est totalement différente de quelqu’un qui tape seul sur Claude Code.

Maintenant, tout le monde aime dire ceci : les développeurs deviendront finalement des chefs d’orchestre, des organisateurs d’agents. Je pense que cette affirmation est juste ; c’est effectivement la trajectoire que nous suivons. Nous devenons de plus en plus des gestionnaires d’agents, appelés à gérer nos relations avec eux.

Mais le problème, c’est que j’entends beaucoup de développeurs dire en privé : nous n’avons pas entré dans ce métier pour faire cela, nous n’avons jamais imaginé de passer autant de temps à optimiser les prompts ou à rédiger de meilleures spécifications. Nous sommes des ingénieurs, nous travaillons sur la technologie, et cela crée une tension identitaire, nous nous demandant sans cesse : est-ce vraiment le rôle que je veux jouer ?

Plus tard, un concept appelé « context engineering » est apparu, offrant ainsi aux développeurs une forme de justification. Il s'agit de dire que ce n'est pas seulement une question d'appeler un prompt ; vous devez également tester, évaluer, distribuer et optimiser les prompts, ce qui confère effectivement une certaine dimension d'ingénierie. Mais franchement, de nombreux développeurs ressentent toujours un vide à ne traiter qu'avec des prompts et des SPEC, se sentant réduits au rôle de « gestionnaires de prompts ».

Mais j'ai observé un tournant intéressant en pratique : lorsque nous avons commencé à introduire Harness, des boucles, et à pousser toute l'organisation vers un niveau plus élevé d'autonomie, une toute nouvelle voie technologique s'est ouverte. Soudain, les développeurs ont dû créer des outils pour les Agents, ce qui a immédiatement ravivé l'enthousiasme d'un certain nombre de personnes. Ceux qui pensaient auparavant « Ce n'est pas mon rôle » se sont soudainement motivés. Ils ont dit : oui, nous pouvons le faire ! Nous maîtrisons cette connaissance ! Nous pouvons améliorer ce système par la programmation. C'est donc intéressant : alors que nous parlions constamment d'« abstraction, abstraction, encore plus d'abstraction », le sentiment de « savoir-faire » est réapparu à un autre niveau, créant un nouvel espace pour des travaux d'ingénierie plus techniques.

On me demande souvent : comment convaincre les personnes sceptiques ? Ma réponse est toujours la même : ces personnes sont en réalité vos trésors. Elles possèdent une quantité considérable de connaissances implicites et de jugement, et vous devez intégrer tout cela dans votre Agent. Vous pouvez leur dire : « Veuillez mettre toutes vos connaissances et votre exigence sur la table », ce qui permettra d’améliorer l’Agent et le Harness. Si vous rencontrez quelqu’un de réticent qui se plaint constamment : « La qualité du code généré est trop mauvaise », considérez-le comme un carburant : transformez cette colère et ce scepticisme en moteur d’amélioration du système.

Permettez-moi de donner une suggestion à nos développeurs : effectuez un changement mental majeur — cessez de corriger le code généré par l’Agent, et concentrez-vous plutôt sur le système qui produit ce code. Comme quelqu’un l’a dit il y a quelques années : « Ne créez pas l’objet, créez l’outil qui le crée. » Nous sommes maintenant à ce niveau d’abstraction, en construisant « l’outil qui crée » à travers le Contexte, le Harness et les boucles. Ceux qui restent encore au stade du « Human in the Loop », de la complétion automatique ou de l’ajustement des prompts, doivent réfléchir à la manière de s’élever vers une approche systémique.

Ce que nous devons vraiment faire, c’est minimiser le nombre d’interventions humaines grâce à de bonnes pratiques d’ingénierie. Au début, tout le monde trouvait « le vibe coding » génial : envoyer un prompt, obtenir un résultat, et continuer sans se soucier du reste. Mais il devient de plus en plus clair que nous ne nous contentons pas de donner des instructions à l’agent via des prompts ; nous lui disons en réalité : « Écris avec des tests, mets à jour la documentation, respecte les normes de codage. » Toutes les choses que nous disions autrefois à un bon ingénieur, nous les répétons maintenant exactement de la même manière à l’agent. Si quelqu’un dans votre équipe utilise encore cette approche sauvage du « YOLO (faites-le marcher d’abord) » pour faire du vibe coding, vous devez l’arrêter immédiatement. Les pratiques d’ingénierie sont essentielles non seulement pour maintenir votre système, mais aussi pour permettre à l’agent de s’améliorer continuellement.

Je commence à observer une nouvelle pratique chez certaines équipes en avance : elles continuent de tenir des réunions de planification et de rétrospective, mais le contenu des discussions a complètement changé. Au lieu de demander « Quel est le problème avec le code ? », elles se demandent désormais « Quel est le problème avec le système ? »

Lors de la réunion de planification, j'ai également observé une répartition intéressante. Les tâches définies de manière très claire et suffisamment précises peuvent être directement confiées à l'Agent, car Harness devient de plus en plus performant et peut gérer ce type de tâches explicites. En revanche, les sujets aux frontières floues, nécessitant des discussions, restent entre les mains des humains. Ainsi, une répartition naturelle s'est établie lors de la réunion : ces cartes suivent directement la chaîne de traitement de l'Agent, tandis que ces autres cartes, nous les discutons.

Les développeurs traversent généralement un cycle d'apprentissage : d'abord, ils apprennent les prompts, puis de meilleures spécifications, ensuite le contexte, les outils de test et les boucles, et toute l'industrie progresse à travers ce cycle. Ce que le chef d'équipe peut faire, c'est fixer le rythme et les contraintes de ce processus, par exemple en disant : « Arrêtez de modifier les prompts, concentrez-vous sur la création d'un contexte réutilisable. » « Parfait, cette étape est terminée, passons à la suivante. » La valeur du chef d'équipe réside dans l'établissement de ce rythme ; simplement dire « Trouvez par vous-mêmes » ne fonctionne pas.

Il y a aussi un effet domino : une fois que la productivité de votre équipe commence à exploser, les équipes en aval, comme celles en charge du GTM (Go to Market), ne pourront plus suivre, voire même les utilisateurs ne pourront plus suivre. Vous devez donc utiliser l’automatisation pour les aider ; votre cadre ne doit pas s’arrêter à la phase de codage, il doit s’étendre jusqu’à eux. Le même principe s’applique aux entrées de besoins en amont : si les demandes n’arrivent pas assez vite, l’équipe sera bloquée, et ces étapes doivent également être intégrées à ce nouveau flux de travail.

Il existe actuellement une multitude d'indicateurs, comme les dépenses en tokens, etc. Mais je commence de plus en plus à croire en deux indicateurs réellement capables de mesurer la productivité. Le premier : comptez combien d'interventions humaines sont encore nécessaires pour qu'un agent accomplisse correctement une tâche. Ce chiffre devrait continuellement diminuer. Plus votre harness est performant, plus votre contexte est riche et plus vos instructions sont claires, plus ce chiffre baisse. Le deuxième indicateur, c'est le effet multiplicateur qui survient lorsque vous passez d'une approche individuelle à un système partagé. Lorsque vous corrigez quelque chose en un seul endroit, tout le monde en bénéficie. Il ne s'agit pas de multiplier l'efficacité d'une personne par dix, mais plutôt que chaque optimisation apportée au système d'agents génère un effet multiplicateur pour tous.

Vous pouvez commencer dans un seul dépôt ou au sein d’une petite équipe, partager le contexte et améliorer ensemble le Harness. Mais ce que vous souhaitez vraiment faire, c’est étendre cet effet à l’ensemble de l’organisation. C’est à ce moment-là que nous devons aborder les équipes plateforme.

L'équipe plateforme est une organisation typiquement partagée ; elle se concentre actuellement sur des éléments tels que l'infrastructure, les services cloud ou la passerelle MCP, et n'accorde pas beaucoup d'attention aux agents. Toutefois, de nombreux nouveaux éléments émergent et nécessitent qu'elle les prenne en charge : un registre de compétences (pour éviter que chacun ne réinvente la même chose dans son coin), un système d'évaluation du contexte (ce contexte a-t-il réellement de la valeur ? Peut-on le quantifier ?), ainsi que des mécanismes de sécurité et de gestion d'identité spécifiques aux agents de codage (au nom de qui l'agent soumet-il le code ? Quelles sont les limites de ses autorisations ?). L'équipe plateforme a donc besoin d'être soutenue pour évoluer vers ce nouveau rôle central.

C’est difficile, et vous devez avoir un propriétaire clair pour piloter cela. Mais qui devrait-ce être ? L’équipe plateforme ? L’équipe expérience développeur ? La première ne touche généralement pas aux éléments de développement, tandis que la seconde ne s’occupe pas beaucoup d’infrastructure ; il faut donc une forme de fusion, mais cette fusion ne se produit pas automatiquement. Vous devez vous assurer qu’il y a un responsable pour pousser ce travail centralisé, sinon votre équipe ne fera que s’occuper de ses propres domaines, sans jamais créer de « Paved Road ».

Pourquoi chaque équipe doit-elle inventer sa propre méthode d’intégration pour le système d’authentification ? C’est un composant partagé qui devrait être intégré au registre. Pourquoi chacun construit-il son propre Harness ? Si nous utilisions tous le même linter et les mêmes outils de scan de sécurité, ce serait un composant réutilisable. Je pense que cela suivra le même chemin que le déploiement des infrastructures cloud à l’époque, pour progressivement se concentrer sur le registre de la plateforme.

Mais le problème, c’est que si n’importe qui peut déposer n’importe quoi dans ce dépôt central, cela va rapidement devenir un désordre (becomes a sprawl). Par exemple, si quelqu’un publie un skill, qui en assure la maintenance ? Une autre personne fork un skill similaire : lequel choisir ? Il faut donc qu’une personne soit clairement désignée comme responsable d’un domaine particulier, et qu’elle garantisse que cet élément est testable et modulaire, permettant à d’autres d’étendre la partie de scan de sécurité dans le Context ou le Harness. Vous devez adopter une approche centralisée, et non laisser circuler librement ces éléments au sein de l’organisation.

Établir un consensus est difficile. Ce n’est pas aussi célèbre que la bataille entre tabs et espaces, mais parfois, ça se sent pareil. Si vous demandez à deux équipes de développement de s’accorder sur leur façon de travailler, cela nécessite une communication et une médiation intensives. En fin de compte, vous finissez probablement non pas avec une seule route goudronnée, mais avec trois ou quatre, parmi lesquelles ils peuvent choisir. S’ils veulent absolument créer leur propre système, c’est possible, mais cela sera à leur propre budget. La voie maintenue de manière centralisée est la « voie facile », conçue pour les inciter à l’emprunter.

Si les gens utilisent aveuglément ces capacités partagées, vous devez leur montrer les coûts. Dès que vous visualisez les dépenses, ils auront naturellement envie d'optimiser. C'est du ressort de l'équipe plateforme de rendre les coûts transparents : combien a-t-on dépensé ? À quel point cela a-t-il aidé ? Si je peux réduire le nombre d'itérations de l'Agent, c'est une optimisation. Mais si je ne vois pas cette métrique, et que je ne vois que le résultat final, je ne peux rien faire : la visualisation est la condition préalable à toute optimisation.

Donc, ma thèse centrale est : nous devons passer d’un modèle de développeurs isolés à un niveau d’équipe avec un contexte partagé et des composants partagés, puis enfin à un « système de jeu multijoueur » au sein de toute l’organisation. L’effet multiplicateur y explosera, car vous aurez une roue motrice dont les améliorations pourront rayonner simultanément dans plusieurs directions.

Au niveau supérieur, comment le VP Ingénierie envisage-t-il cette question ? Je peux presque prédire l'histoire qui se déroulera dans votre organisation : un hackathon ou une séance de partage au déjeuner, la présentation de cas réussis, la création d'un canal Slack partagé, la mise en place d'un programme de champions. Ce sont tous des schémas de transformation classiques. L'adoption d'Agile l'a déjà fait, DevOps aussi — rien de nouveau sous le soleil.

D’un autre côté, nous savons également que la stratégie consistant à « délivrer des licences, organiser des formations, laisser tout le monde s’exprimer librement et faire s’épanouir mille fleurs » n’a jamais réussi. Le résultat de mille fleurs est généralement mille mauvaises herbes : une floraison abondante, mais aucune fleur ne donne de fruit. Je propose donc que, du côté de l’organisation, une autorisation claire soit accordée aux chefs d’équipe et à l’équipe plateforme pour mener cette initiative. Ce n’est pas quelque chose qu’un seul individu exceptionnel peut accomplir ; il faut quelqu’un qui soit officiellement mandaté pour la faire avancer.

Demander de l'aide pour recruter est aussi une source de stress. Les intitulés de postes actuels sont un vrai désordre : ingénieur produit IA, forward deployed engineer, ingénieur agentic, ingénieur IA… Ces termes n'ont en réalité aucune signification concrète. Vous ne pouvez pas juger la maturité d'une personne à partir de son titre, car toute l'industrie est encore immature. Cependant, lors de la publication d'une offre d'emploi, ces termes peuvent effectivement émettre certains signaux et attirer les candidats intéressés, mais ils ne garantissent en rien que la personne possède les compétences correspondantes. J'ai aussi entendu des histoires encore plus folles : certains candidats utilisent l'IA pour leur fournir des réponses en temps réel dans l'oreille pendant les entretiens ; chaque fois que le recruteur pose une question, une suggestion de l'IA leur parvient via leurs AirPods.

Je constate de plus en plus d'entreprises adopter ce type d'entretien. Première étape : proposer un exercice et leur demander d'utiliser l'IA librement, autant que possible. Si l'IA les aide à résoudre le problème, cela démontre précisément leur capacité à exploiter l'IA. Deuxième étape : leur demander d'analyser leur propre solution et d'expliquer : « Pourquoi avez-vous choisi cette approche ? Comment avez-vous vérifié qu'elle était correcte ? » Ici, vous évaluez leur capacité à tester et leur jugement technique. La première partie teste la maîtrise de l'IA, la seconde la solidité technique. Troisièmement, observez comment ils collaborent : sont-ils ouverts à partager ou préfèrent-ils travailler seuls ? Certains ont un fort potentiel technique mais veulent tout contrôler eux-mêmes ; dans l'ère des agents, ce type de personne devient un goulot d'étranglement.

La personne que vous cherchez est celle qui combine à la fois une utilisation exceptionnelle de l’IA, une solide expertise technique et une volonté sincère de partager et de collaborer. Ce n’est pas quelqu’un qui a simplement suivi des cours de ML ou d’IA, ni un expert en décryptage, mais plutôt un mélange unique. Il est probable que vous ne trouviez personne qui réunisse parfaitement ces trois critères — et ce n’est pas grave : un candidat peut être particulièrement fort dans un domaine tout en ayant besoin de guidance dans un autre. En outre, ne mélangez pas ces compétences sous des étiquettes génériques comme « débutant » ou « avancé » ; ce sont des dimensions distinctes : une personne peut avoir une capacité d’exploitation de l’IA « avancée » tout en ayant une volonté de collaboration « débutante ».

Le département ingénierie doit rendre des comptes à la direction. Nous avons acheté tant de licences, pouvons-nous démontrer un retour sur investissement ? Les livraisons sont-elles plus rapides ? Il peut y avoir des engagements, mais il est difficile à prouver. La qualité s’est-elle améliorée ? Il est tout aussi difficile à affirmer. Mais revenons aux deux indicateurs que j’ai mentionnés précédemment : vous pouvez montrer de combien les interventions ont diminué, de combien elles ont été améliorées, et de combien le taux de réutilisation a augmenté. C’est bien plus facile et plus convaincant que de comparer la productivité de codage « avec ou sans agent ».

Ainsi, lorsque quelqu’un se plaint que l’Agent coûte trop cher et propose de limiter le budget, votre réaction instinctive ne devrait pas être « supprimons toutes les dépenses », mais plutôt « comment optimiser ces dépenses » ? La méthode la plus simple consiste à choisir le bon modèle : toutes les tâches n’ont pas besoin du modèle le plus puissant ; certaines peuvent être traitées efficacement avec un modèle moins coûteux. Éduquez les développeurs sur quel modèle utiliser dans quel contexte, et allez plus loin en leur fournissant un meilleur contexte et des outils adaptés : cela permettra à l’Agent d’éviter les erreurs et de réduire considérablement les coûts.

Il y a aussi le sujet de la taille de l’équipe. Un talent polyvalent qui fait tout est bien sûr le rêve ultime. Mais si vous faites le calcul précis : cette personne a généralement besoin de compétences complémentaires, comme un produit manager ou un designer. Ensuite, il faut prévoir des remplaçants (backup) au cas où quelqu’un prendrait des vacances — ce qui ramène déjà à trois personnes. Puis, il faut peut-être quelqu’un pour surveiller la production et les tickets ; si vous êtes extrêmement efficace, ce pourrait être les mêmes personnes en double fonction. Mais dès que vous devez corriger des bugs, votre vitesse de développement de nouvelles fonctionnalités ralentit. Enfin, il y a les nouveaux arrivants : vous devez leur montrer ce que signifie « bien faire ». Je reste donc convaincu que, dans une organisation, il est impossible de réduire chaque équipe à une ou deux personnes.

Enfin, une usine sombre n’est peut-être pas entièrement sombre, mais conserve une légère lueur (dim factory), ce qui signifie que vous devez déterminer le niveau de risque que vous acceptez pour chaque fonctionnalité : toutes ne sont pas adaptées à une autonomie complète. Vous pouvez investir davantage dans l’audit, par exemple en traçant l’origine des modifications : qui a modifié le code ? Une personne ou un agent ? Ajoutez des validateurs pour vérifier que le code est effectivement utile, et investissez dans des capacités de contexte lorsque les processus automatisés échouent. Il existe tout un spectre allant d’une micro-gestion totale (chaque ligne de code doit être examinée par un humain) à une approbation entièrement autonome (en supposant que les résultats de l’agent sont toujours corrects). Votre tâche consiste à choisir le niveau d’automatisation approprié pour chaque type de modification en fonction de son niveau de risque.

Et je pense que votre avantage concurrentiel réside dans la capture des connaissances accumulées — ces contextes métier que vous incorporez actuellement dans Skill, Context et même les contraintes de Harness. Pour moi, cela transforme la livraison continue en apprentissage continu. Posez-vous cette question : à quelle vitesse pouvons-nous intégrer une nouvelle chose dans le système et en retirer une ancienne ? C’est votre capacité de réaction. Si vous pouvez améliorer continuellement cette capacité, la question cruciale ne sera plus « Comment rendre tout le système plus fiable ? », mais « Puis-je maintenir sa fiabilité tout en modifiant de plus en plus de parties du système ? »

Si vous ne retenez qu'une seule phrase, ce devrait être : Les gagnants ne seront pas les joueurs solitaires surpuissants, mais ceux qui savent améliorer leur organisation à plusieurs niveaux.