L’ancien fondateur technique de Meta partage trois choses que tout directeur technique doit faire avant de toucher à l’IA

James Everingham a dirigé l'ingénierie de certaines des entreprises les plus avancées au monde, notamment Meta. Il est actuellement PDG et cofondateur de Guild.ai, un plan de contrôle pour les agents IA, qui offre aux organisations un point unique pour déployer, gouverner, observer et optimiser chaque agent en production.

Nous nous sommes entretenus avec James pour comprendre comment l'IA transforme les flux de travail d'ingénierie — et ce que les équipes d'ingénierie doivent changer avant que l'IA puisse être intégrée efficacement. Voici ce qu'il nous a expliqué.

De Meta à la start-up spécialisée dans l'IA

Je suis le PDG et cofondateur de Guild.ai, le plan de contrôle pour les agents IA, qui offre aux organisations un point unique pour déployer, gouverner, observer et optimiser chaque agent en production. Nous avons levé 44 millions de dollars — une série A menée par Google Ventures, avec la participation de NFX, Acrew, Scribble Ventures, Khosla Ventures et Webb Investment Network. Notre équipe compte environ 35 personnes et est basée à San Francisco.

Avant cela, j'étais vice-président de l'ingénierie chez Meta DevInfra, où je développais et dirigeais les outils, services et plateformes essentiels pour développeurs qui alimentaient les produits de Meta. Mon équipe a créé le premier agent IA interne de Meta, ce qui a eu un impact immédiat sur la manière dont les ingénieurs de Meta utilisaient les outils d'IA. Pendant mon passage chez Meta, j'ai également cocréé Diem et occupé le poste de responsable de l'ingénierie d'Instagram.

Fort d'une carrière de 40 ans en tant que manager, entrepreneur et développeur de technologies, j'ai dirigé de nombreuses équipes d'ingénierie de renommée mondiale. Chez Yahoo, j'étais vice-président de l'ingénierie pour les activités médias de Yahoo après l'acquisition de Luminate, une entreprise de technologie d'image interactive que j'avais fondée. Auparavant, j'avais dirigé des équipes chez Oracle, Netscape Communications, Tellme (rachetée par Microsoft), ainsi que dans plusieurs de mes propres entreprises.

Comment l'IA a contribué à supprimer le gel annuel du code chez Meta

Lorsque je travaillais chez Meta, nous avons utilisé un modèle de risque basé sur l'IA pour supprimer le gel annuel du code.

Auparavant, Meta gelait sa base de code chaque année de la mi-décembre à janvier, car il s'agit de la période de plus forte fréquentation pour ses produits. Pendant des années, afin d'éviter les incidents en production durant les semaines les plus risquées, personne ne déployait de code. Cette approche était sûre, mais elle paralysait également la productivité de toute l'entreprise pendant plus d'un mois.

Mon équipe a créé et publié en logiciel libre Diff Risk Score, un système alimenté par un grand modèle de langage qui évalue la probabilité qu'une différence de code provoque une panne en production. Au lieu de considérer chaque modification comme présentant le même niveau de danger pendant la période de gel, le modèle effectuait un triage des risques. Il attribuait un score de risque continu à chaque différence, réglé pour privilégier un rappel élevé — par exemple, en signalant 10 % des différences tout en détectant 60 % des modifications qui provoquent effectivement des incidents. Le modèle permettait aux différences à faible risque d'être intégrées même pendant le gel, mais bloquait celles qu'il signalait comme risquées.

Résultat : le gel n'est plus une mesure tout ou rien. Et Diff Risk Score permet à Meta de commencer à supprimer complètement le gel du code — les ingénieurs récupèrent des semaines de leur calendrier qui étaient auparavant perdues, sans sacrifier le filet de sécurité fourni par le gel.

C'est un bon exemple de ma philosophie générale : ne donnez pas aux ingénieurs une directive descendante sur l'IA, donnez-leur une infrastructure — une plateforme centralisée, un signal de risque, un plan de contrôle — et laissez-les trouver eux-mêmes les leviers d'action.

Pourquoi les humains doivent être capables d'expliquer le code avant sa mise en production

Si vous ne pouvez pas l'expliquer, vous ne pouvez pas le déployer.

J'utilise intensivement les outils d'IA pour accélérer le travail, mais je conseille aux ingénieurs de toujours exiger une validation avant que quoi que ce soit n'atteigne la production. L'IA ne remplace pas le jugement des ingénieurs ; elle leur donne davantage de leviers pour appliquer ce jugement à grande échelle.

L'IA contribue désormais au travail d'évaluation des risques, ainsi qu'à la découverte d'outils et de flux de travail.

Les domaines où les humains sont les meilleurs :

• Gouvernance et garde-fous autour des agents eux-mêmes : Lorsque les équipes intègrent des modèles de raisonnement et des agents en profondeur dans l’infrastructure, elles constatent rapidement des défaillances de gouvernance — les agents se multiplient plus vite que prévu et les budgets s’évaporent du jour au lendemain. Il faut appliquer aux agents non déterministes la même couche de gouvernance que celle mise en place pour les humains utilisant cette infrastructure — ce qui signifie que les humains continuent de définir les limites budgétaires, les périmètres d’accès et les exigences d’audit.
• Stratégie d’adoption : Il ne faut pas imposer l’adoption des outils d’IA — l’utilisation obtenue par l’adhésion est préférable à celle imposée, car les obligations produisent une adoption superficielle. Décider comment intégrer l’IA au flux de travail d’une équipe relève pleinement d’une décision humaine de leadership et de culture — l’outil peut faire ses preuves, mais la décision d’adoption ne peut pas être automatisée.

Pourquoi les équipes d’ingénierie doivent repenser leur architecture

Les débuts de l’informatique reposaient sur un grand ordinateur central partagé par tous, avant de passer à des racks de serveurs exécutant des services spécialisés. Les agents suivent la même trajectoire.

L’ancienne hypothèse consistait à créer une poignée d’agents polyvalents et à centraliser leur utilisation autour d’eux, comme pour centraliser les ressources de calcul. Mais les entreprises se rendent compte que leur réalité ne se résume pas à quelques outils partagés — elle ressemble davantage à un écosystème d’agents spécialisés et conçus pour un objectif précis. Cela oblige à repenser ce que signifie réellement l’« architecture » pour une base de code : moins un monolithe avec des extensions, davantage un univers de microservices, à ceci près que les services sont des agents plutôt que des points de terminaison.

Dans la plupart des organisations, le réflexe consiste à traiter un agent comme n’importe quel autre logiciel — rédiger les spécifications, le déployer et s’attendre à des résultats cohérents. J’ai abandonné cette approche pour adopter un modèle mental fondé sur une main-d’œuvre. Cela reformule les questions de conception organisationnelle — qui approuve quoi, qui détient le budget, qui est responsable lorsqu’un problème survient — en questions de management, et non de déploiement. C’est une autre manière de structurer la relation d’une équipe avec ses outils.

Pourquoi la gouvernance doit être en place avant que l’adoption de l’IA ne décolle

Dans mes fonctions précédentes, j’aurais aimé que nous construisions la couche de gouvernance avant que l’adoption ne décolle, et non après.

Lorsque je travaillais chez Meta, les ingénieurs ont commencé à créer et à publier leurs propres agents sur la plateforme interne ; les agents se sont rapidement multipliés et l’équipe chargée de l’infrastructure s’est soudainement retrouvée à devoir répondre à la demande — en essayant littéralement de trouver des dizaines de milliers de serveurs disponibles.

Avec le recul, cela aurait pu être évité. Si l’on part du principe que l’adoption pourrait devenir virale en interne, il faut intégrer les contrôles des coûts et les périmètres d’accès à la plateforme dès le premier jour, plutôt que de les ajouter dans le cadre d’une gestion de crise.

Les CTO doivent repenser la frontière entre « où se trouve l’IA » et « ce que l’IA peut toucher » — en la déplaçant de l’éditeur vers leur infrastructure, car c’est à ce niveau que le risque prend naissance et que la gouvernance doit être établie.

James partage

Les CTO doivent repenser la frontière entre “où se trouve l’IA” et “ce que l’IA peut toucher” — en la déplaçant de l’éditeur vers leur infrastructure, car c’est à ce niveau que le risque prend naissance et que la gouvernance doit être établie.

Pourquoi les organisations doivent disposer d’un espace centralisé où les agents peuvent être dérivés

En tant qu’ingénieur, j’étais meilleur pour détourner le travail des autres que pour coder. Je trouvais quelque chose qui répondait partiellement à mes besoins, je l’adaptais à mon objectif précis et j’apprenais chemin faisant.

La première étape du flux de travail n’est pas de « demander quelque chose à un modèle » ; elle consiste à parcourir un espace centralisé pour voir quels agents existent déjà pour cette tâche et à en dériver un plutôt que de partir de zéro. Les organisations doivent créer des processus permettant de récupérer facilement les agents existants.

Trois conseils pour les CTO qui intègrent l’IA dans les organisations techniques

Voici mes conseils :

1. Ne l'imposez pas — gagnez l'adhésion. L'utilisation imposée de l'IA pour améliorer la productivité me frustre, car elle entraîne une adoption superficielle — les meilleurs outils pour les développeurs gagnent leur usage, et les développeurs sont suffisamment intelligents pour résister lorsqu'on leur dit quels outils ils doivent apprécier. Les CTO doivent présenter à l'organisation des défis commerciaux d'une ampleur considérable — des problèmes si importants que l'IA est la seule solution réaliste. Ensuite, laissez les ingénieurs qui les résolvent devenir des ambassadeurs spontanés. 
2. Cessez de considérer l'IA comme un outil de création et commencez à la considérer comme une infrastructure. 2025 a été l'année où les outils de codage comme Cursor et Copilot se sont généralisés ; désormais, les modèles de raisonnement et les agents multi-étapes cessent d'être des extensions d'éditeur et deviennent plutôt une partie de l'infrastructure des entreprises — soumission de code, exécution de tests, intégration de nouveaux ingénieurs et gestion du comportement en production. Si votre stratégie en matière d'IA se résume encore à « quel module d'extension pour IDE devrions-nous acheter ? », vous cherchez à résoudre un ancien problème.
3. Gouvernez les agents comme vous gouverneriez une main-d'œuvre, et non comme vous gouverneriez des logiciels. Les agents alimentés par des modèles de raisonnement sont non déterministes — donnez deux fois la même entrée au même agent, et vous pouvez obtenir des résultats différents. Ce n'est pas un bug à corriger ; c'est la nature fondamentale de cette technologie. Les CTO gèrent déjà quotidiennement des systèmes non déterministes avec leurs employés. Vous devez appliquer aux agents certaines des mêmes garde-fous que ceux que vous appliquez à votre personnel. Ne donnez pas à un agent un accès illimité à la production, des identifiants root ou un budget cloud illimité dès le premier jour, pas plus que vous ne donneriez ces accès à une personne qui vient d'être embauchée.

Suivez son actualité

Vous pouvez suivre les travaux de James Everingham sur X et LinkedIn.

D'autres entretiens avec des experts seront bientôt publiés sur The CTO Club !