L’ancien fondateur technologique 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 d'IA, qui offre aux organisations un emplacement 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 de pouvoir intégrer efficacement l'IA. Voici ce qu'il nous a expliqué.

De Meta à une 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 d'IA, qui offre aux organisations un emplacement 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.

Auparavant, j'étais vice-président de l'ingénierie chez Meta DevInfra, où je construisais et dirigeais les outils, services et plateformes de développement essentiels qui alimentaient les produits de Meta. Mon équipe a créé le premier agent d'IA interne de Meta, avec 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 participé à la création de Diem et occupé le poste de responsable de l'ingénierie d'Instagram.

Au cours d'une carrière de 40 ans comme manager, entrepreneur et développeur de technologies, j'ai dirigé de nombreuses équipes d'ingénierie de classe mondiale. Chez Yahoo, j'étais vice-président de l'ingénierie pour les propriétés média de Yahoo après l'acquisition de Luminate, une entreprise de technologies d'images interactives que j'avais fondée. Auparavant, j'avais dirigé des équipes chez Oracle, Netscape Communications, Tellme (rachetée par Microsoft) et dans plusieurs de mes propres entreprises.

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

Lorsque j'étais chez Meta, nous avons utilisé un modèle de risque basé sur l'IA pour mettre fin au 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 où ses produits enregistrent le plus fort trafic. Pendant des années, afin d'éviter les incidents en production au cours des semaines les plus risquées, personne ne déployait de code. Cette pratique était sûre, mais elle a également paralysé la productivité de toute l'entreprise pendant plus d'un mois.

Mon équipe a créé et publié en open source 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 un plantage en production. Au lieu de considérer chaque modification comme présentant le même 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 obtenir 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 présentant peu de risques d'être intégrées même pendant le gel, mais bloquait celles qu'il signalait comme risquées.

Par conséquent, 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 du temps perdu, sans sacrifier le filet de sécurité offert par le gel.

C'est un bon exemple de ma philosophie générale : ne donnez pas aux ingénieurs une directive d'IA imposée d'en haut, 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 à exploiter.

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 éclaire désormais le travail d'évaluation des risques, ainsi que la découverte des outils et des 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 profondément des modèles de raisonnement et des agents 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. Vous avez besoin du même niveau de gouvernance autour des agents non déterministes que celui que vous mettriez 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 : Vous ne pouvez pas imposer l’adoption des outils d’IA — l’utilisation gagnée par la confiance est plus efficace que l’utilisation 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 entièrement du leadership humain et de la 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 seul ordinateur central partagé par tous, puis ont évolué vers 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 on centralisait les capacités 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 des tâches précises. Cela oblige à repenser ce que signifie réellement « architecture » pour une base de code : moins un monolithe avec des extensions, davantage un univers de microservices, sauf 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 livrer et s’attendre à des résultats cohérents. J’ai abandonné cette approche pour la remplacer par 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 plutôt qu’en questions de déploiement. C’est une autre façon de structurer la relation d’une équipe avec ses outils.

Pourquoi la gouvernance doit être en place avant l’essor de l’adoption de l’IA

Dans mes fonctions précédentes, j’aurais aimé que nous mettions en place le niveau de gouvernance avant l’essor de l’adoption, 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 multipliés rapidement et l’équipe chargée de l’infrastructure s’est soudain retrouvée à courir pour répondre à la demande — elle essayait littéralement de trouver des dizaines de milliers de serveurs disponibles.

Avec le recul, cela aurait pu être évité. Si vous partez du principe que l’adoption pourrait devenir virale en interne, vous intégrez 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 gérer dans le cadre d’une intervention d’urgence.

Les CTO doivent repenser la frontière entre « où vit 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 se trouver.

James partage

Les CTO doivent repenser la frontière entre “l’endroit où vit 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 se trouver.

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

En tant qu’ingénieur, j’étais meilleur pour dérober que pour coder. Je trouvais quelque chose qui répondait en partie à mes besoins, je l’adaptais à mon objectif précis et j’apprenais au passage.

La première étape du flux de travail n’est pas de « donner une instruction à un modèle » ; c’est de parcourir un espace centralisé pour voir quels agents existent déjà pour cette tâche et d’en cloner un plutôt que de partir de zéro. Les organisations doivent créer des processus permettant de dérober facilement des agents.

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

Voici mes conseils :

1. Ne l'imposez pas — faites-le adopter. L'utilisation obligatoire de l'IA pour gagner en productivité me frustre, car elle entraîne une adoption superficielle — les meilleurs outils pour développeurs gagnent leur adoption, et les développeurs sont suffisamment intelligents pour résister lorsqu'on leur dit quels outils ils doivent apprécier. Les CTO devraient 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 programmation comme Cursor et Copilot se sont généralisés ; désormais, les modèles de raisonnement et les agents capables d'effectuer plusieurs étapes cessent d'être de simples extensions d'éditeurs et deviennent 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 consiste encore à vous demander « quel module d'extension pour IDE devons-nous acheter ? », vous tentez de résoudre un problème dépassé.
3. Gérez les agents comme vous géreriez une équipe, et non comme vous géreriez un logiciel. 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 bogue à 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 mesures de protection que celles appliquées à 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 nouvellement 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 !