Livre blanc · 14 pages · par Bo Wesdorp
Comment l'IA a changé l'ingénierie
Depuis 2022, les équipes d'ingénieurs ont adopté les outils d'IA en six vagues, de l'autocomplétion dans l'éditeur aux agents qui tournent seuls. Cette page suit ce parcours : quels outils sont arrivés quand, comment chacun a changé le travail au quotidien, et ce qu'ont fait différemment les équipes qui en ont tiré le plus.
J'ai repensé quatre fois la façon de travailler de nos ingénieurs depuis 2022. À chaque fois, quelque chose est arrivé qui levait une contrainte, et en quelques mois il était clair que le travail n'avait pas disparu. Il s'était déplacé.
La plupart des équipes que je rencontre ont acheté les outils dans cet ordre et n'ont rien changé d'autre. Elles ont des licences Copilot de 2023 et des budgets d'agents de cette année, qui tournent avec un processus de revue, une définition du « terminé » et un plan d'effectifs qui datent de l'époque où écrire du code était la partie coûteuse.
Sur nos propres projets, 80 à 90 % du code de production sort désormais d'un modèle. Cela ne nous a pas rendus plus rapides à lui seul. C'est la refonte de tout ce qui l'entoure qui a fait passer dix ingénieurs à quatre.
Quatre ans d'outils d'IA en ingénierie
La plupart des équipes ont acheté ces outils dans cet ordre, sans rien changer autour. Choisissez une vague pour voir ce que les équipes ont adopté, comment le travail a changé et ce qu'elle a laissé à la vague suivante. La stack se construit au fil du parcours.
2022 à 2023 · Vague 1
Complétion
- Ce que les équipes ont adopté
- Les équipes ont acheté des licences GitHub Copilot. La complétion vivait dans l’éditeur et ne demandait à personne de changer sa façon de travailler. C’est pourquoi elle s’est répandue aussi vite.
- Comment le travail a changé
- Les ingénieurs ont cessé de taper du code répétitif et ont pris l’habitude d’accepter les suggestions avec la touche Tab.
- Laissé à la vague suivante
- Décider quoi écrire
2023 à 2024 · Vague 2
Chat
- Ce que les équipes ont adopté
- Les ingénieurs gardaient ChatGPT ou Claude ouvert à côté de l’éditeur et copiaient le code dans les deux sens. GitHub Copilot Chat l’a intégré à l’IDE, et Cursor a mis fin à cette période en laissant le modèle lire tout le dépôt.
- Comment le travail a changé
- Le travail commençait par décrire le problème avec des mots au lieu d’écrire le code.
- Laissé à la vague suivante
- Faire en sorte que le modèle comprenne votre système
2024 à 2025 · Vague 3
Contexte
- Ce que les équipes ont adopté
- Le Model Context Protocol est arrivé fin 2024. Les équipes ont ajouté des fichiers CLAUDE.md, AGENTS.md et .cursorrules à leurs dépôts, et Aider, Cline et Windsurf ont introduit l’édition agentique dans l’éditeur.
- Comment le travail a changé
- Les ingénieurs ont commencé à écrire pour le modèle : des fichiers de contexte dans le dépôt et des connexions en direct aux tickets, aux schémas et aux journaux d’erreurs.
- Laissé à la vague suivante
- Décider ce que le modèle a le droit de faire
Début 2026 · Vague 4
Harness
- Ce que les équipes ont adopté
- Claude Code avec ses hooks, skills et subagents, OpenAI Codex et LangChain Deep Agents ont fait du modèle un agent. Langfuse et Braintrust ont montré ce que l'agent faisait réellement.
- Comment le travail a changé
- L'agent a lancé les tests, lu l'échec, corrigé le code et ouvert la pull request. Les ingénieurs ont configuré ce à quoi il avait le droit d'accéder.
- Laissé à la vague suivante
- Lui donner un prompt à chaque tour, et le jugement placé dans la configuration
Mi-2026 · Vague 5
Boucle
- Ce que les équipes ont adopté
- Claude Code a lancé /loop en mars 2026, Codex a ajouté les goals, et l'agent de code GitHub Copilot ainsi qu'OpenClaw ont pris en charge des tâches à partir de tickets. La CI existante est devenue le déclencheur et, le plus souvent, le vérificateur.
- Comment le travail a changé
- Les agents tournent selon un calendrier ou sur un événement, sans que quelqu'un valide chaque tour. Les ingénieurs conçoivent le contrôle qui leur indique de s'arrêter.
- Laissé à la vague suivante
- Vérifier ce qui revient
Aujourd'hui · Vague 6
Vérification
- Ce que les équipes ont adopté
- Les équipes ajoutent de la revue par IA (CodeRabbit, Greptile, Qodo, Graphite), l'analyse de ce à quoi l'agent a eu accès (Semgrep, Snyk, Socket) et des outils qui montrent la file de revue (Faros, LinearB). Les équipes qui avancent le plus vite changent aussi l'ordre du travail.
- Comment le travail a changé
- La spec et les tests d'acceptation sont écrits avant que l'agent démarre. La plupart des changements sont donc vérifiés automatiquement, et les équipes ne relisent que ceux qui présentent un risque.
- Laissé à la vague suivante
- Écrire la spec et les tests une seule fois, avant que l'agent ne tourne
2022 à 2023 · Complétion
Vague 1 sur 6La complétion a retiré la frappe du travail
Ce que les équipes ont adopté
Les équipes ont acheté des licences GitHub Copilot. La complétion vivait dans l’éditeur et ne demandait à personne de changer sa façon de travailler. C’est pourquoi elle s’est répandue aussi vite.
Comment le travail a changé
Les ingénieurs ont cessé de taper du code répétitif et ont pris l’habitude d’accepter les suggestions avec la touche Tab.
GitHub Copilot a placé un modèle dans l'éditeur, qui terminait la ligne en cours de frappe. Il a retiré le code répétitif du travail, et personne ne regrette cette tâche.
Il a aussi rendu la mauvaise approche aussi rapide à écrire que la bonne. La contrainte est passée de la vitesse de frappe à la capacité de savoir quoi écrire.
Où se concentre l'attention
Connaître la bonne approche avant que la suggestion n'apparaisse. Une mauvaise réponse rapide reste une mauvaise réponse.
- Résolu
- Le code répétitif et la ligne de code suivante
- Laissé à la vague suivante
- Décider quoi écrire
Les outils de cette vague
Testons-nous cela ?
En partieNous testons ce que la complétion ne fait pas à votre place
Personne n'est noté sur sa vitesse de frappe ni sur sa manière d'utiliser l'autocomplétion. L'évaluation des fondamentaux se déroule avec tous les outils d'IA désactivés, car un ingénieur qui ne sait pas raisonner sur un système sans suggestions ne peut pas voir quand une suggestion est fausse.
2023 à 2024 · Chat
Vague 2 sur 6Le chat a converti une description en bloc de code
Ce que les équipes ont adopté
Les ingénieurs gardaient ChatGPT ou Claude ouvert à côté de l’éditeur et copiaient le code dans les deux sens. GitHub Copilot Chat l’a intégré à l’IDE, et Cursor a mis fin à cette période en laissant le modèle lire tout le dépôt.
Comment le travail a changé
Le travail commençait par décrire le problème avec des mots au lieu d’écrire le code.
ChatGPT et Claude ont converti la description d'un problème en bloc de code. Pour un ingénieur confirmé, ce fut le plus grand bond de toute la chronologie.
Aucun des deux ne voyait votre système. Une année de prompt engineering a suivi : une vraie compétence, appliquée à la mauvaise couche. Le chat a aussi formé les ingénieurs qui lisaient l'explication et accéléré ceux qui ne la lisaient pas.
Où se concentre l'attention
Lire l'explication en plus du code, et repérer quand la réponse a été écrite pour un système qui n'est pas le vôtre.
- Résolu
- Transformer un problème décrit en code qui fonctionne
- Laissé à la vague suivante
- Faire en sorte que le modèle comprenne votre système
Les outils de cette vague
Testons-nous cela ?
OuiNous testons s'ils savent expliquer une modification qu'ils n'ont pas tapée
Dans l'évaluation AI-native, l'ingénieur travaille avec ses propres outils et nous lui demandons pourquoi l'agent a choisi cette approche. « C'est l'agent qui l'a fait » n'est pas une explication que nous acceptons. Un ingénieur qui relance le même prompt vague au lieu de corriger l'entrée obtient une note basse.
2024 à 2025 · Contexte
Vague 3 sur 6Le contexte a fait de ce que l'on donne au modèle le produit
Ce que les équipes ont adopté
Le Model Context Protocol est arrivé fin 2024. Les équipes ont ajouté des fichiers CLAUDE.md, AGENTS.md et .cursorrules à leurs dépôts, et Aider, Cline et Windsurf ont introduit l’édition agentique dans l’éditeur.
Comment le travail a changé
Les ingénieurs ont commencé à écrire pour le modèle : des fichiers de contexte dans le dépôt et des connexions en direct aux tickets, aux schémas et aux journaux d’erreurs.
C'est le moment où le secteur a cessé de voir le modèle comme le produit et a commencé à voir ce qu'on lui fournit comme le produit. C'est aussi la couche sur laquelle restent encore la plupart des équipes, quoi qu'elles pensent d'elles-mêmes.
Ce que personne ne signale, c'est la dégradation. Le fichier exact en mars décrit un système qui n'existait plus en septembre. Un fichier de contexte périmé est pire que pas de fichier : il rend l'agent sûr de lui et pourtant dans l'erreur, d'une façon qui passe la revue. Nous comptons sa mise à jour dans la définition de « terminé ».
CLAUDE.md, AGENTS.md et .cursorrules contiennent ce qu'un nouvel ingénieur aurait besoin de savoir, écrit là où l'outil le lit à chaque exécution.
Publié par Anthropic fin 2024, c'est un standard pour donner à un modèle accès à ce qui n'est pas des fichiers : le suivi des tickets, le schéma, le journal d'erreurs.
Où se concentre l'attention
Tenir les fichiers de contexte à jour. Un CLAUDE.md périmé produit un travail sûr de lui qui passe la revue.
- Résolu
- Le modèle peut lire votre dépôt, vos tickets et votre schéma
- Laissé à la vague suivante
- Décider ce que le modèle a le droit de faire
Les outils de cette vague
Testons-nous cela ?
OuiNous évaluons le contexte qu'ils mettent en place et ce qu'ils laissent derrière eux
Le prompt and context engineering est l'un des six critères AI-native : la configuration produit-elle un résultat exploitable en une ou deux passes ? Nous regardons aussi ce qui sert la suite, comme un CLAUDE.md plus précis ou une commande réutilisable qui facilite le ticket suivant.
Début 2026 · Harness
Vague 4 sur 6Le harness : un agent est un modèle plus tout ce qui l'entoure
Ce que les équipes ont adopté
Claude Code avec ses hooks, skills et subagents, OpenAI Codex et LangChain Deep Agents ont fait du modèle un agent. Langfuse et Braintrust ont montré ce que l'agent faisait réellement.
Comment le travail a changé
L'agent a lancé les tests, lu l'échec, corrigé le code et ouvert la pull request. Les ingénieurs ont configuré ce à quoi il avait le droit d'accéder.
Le vocabulaire est apparu en février 2026. Mitchell Hashimoto a employé l'expression harness engineering et, en quelques semaines, elle est devenue une discipline fondée sur une seule phrase : un agent, c'est un modèle plus un harness.
Le modèle est la partie que vous ne maîtrisez pas et que vous pouvez remplacer. Le harness, c'est tout le reste : la boucle qui l'exécute, les outils qu'il peut appeler, la façon dont son contexte est compacté quand une tâche s'allonge, la sandbox dans laquelle il s'exécute, les limites de permissions, les hooks qui se déclenchent avant et après une action, les sous-agents qu'il peut lancer, et l'observabilité qui indique ensuite ce qu'il a fait. Cela explique pourquoi deux entreprises qui ont le même modèle et la même licence obtiennent des résultats très différents.
La sécurité a changé de forme. Un harness est un système qui détient des identifiants et des accès à des outils, avec un modèle qui décide quoi appeler. Ce que vous relisez n'est donc plus seulement le code. C'est aussi ce que l'agent avait le droit d'atteindre.
Où se concentre l'attention
Les choix faits dans la configuration. Les outils que l'agent peut appeler, l'emplacement de la limite de la sandbox et ce qu'un hook bloque s'appliquent désormais à tout ce que l'équipe livre.
- Résolu
- Un agent capable de terminer une tâche : lancer les tests, lire l'échec, le corriger et ouvrir la pull request
- Laissé à la vague suivante
- Lui donner un prompt à chaque tour, et le jugement placé dans la configuration
Les outils de cette vague
Testons-nous cela ?
En partieNous testons l'orchestration, pas la construction complète d'un harness
L'orchestration des outils est notée dans l'évaluation AI-native : ce que l'ingénieur confie à l'agent, ce qu'il garde, et s'il exécute des tâches en parallèle dans des worktrees. Concevoir la sandbox, les permissions et les hooks d'une équipe ne tient pas en soixante minutes. Pour les postes plateforme, l'évaluation DevOps ajoute donc une modification de pipeline générée, avec une permission plus large qu'elle n'en a l'air.
Mi-2026 · Boucle
Vague 5 sur 6La boucle exécute des agents sans que quelqu'un valide chaque tour
Ce que les équipes ont adopté
Claude Code a lancé /loop en mars 2026, Codex a ajouté les goals, et l'agent de code GitHub Copilot ainsi qu'OpenClaw ont pris en charge des tâches à partir de tickets. La CI existante est devenue le déclencheur et, le plus souvent, le vérificateur.
Comment le travail a changé
Les agents tournent selon un calendrier ou sur un événement, sans que quelqu'un valide chaque tour. Les ingénieurs conçoivent le contrôle qui leur indique de s'arrêter.
Nous avions des agents capables de terminer de vraies tâches, et des ingénieurs seniors assis devant leur écran à valider chaque tour. Un harness équipe une exécution. Une boucle en enchaîne plusieurs, déclenchées par un planning ou un événement et bornées par un critère qu'une machine peut vérifier.
Claude Code a lancé /loop en mars 2026 et Codex a ajouté les goals en avril. Votre CI existante sert en général de déclencheur et de vérificateur.
Où se concentre l'attention
Le vérificateur et la condition d'arrêt. Les deux sont conçus avant que la boucle ne tourne.
- Résolu
- Un ingénieur senior qui tape « oui, continue » dans quatre fenêtres
- Laissé à la vague suivante
- Vérifier ce qui revient
Une boucle qui fonctionne
- Le vérificateur est conçu avant la boucle
- La condition d'arrêt est vérifiable par une machine
- Elle tourne d'abord sur un périmètre étroit et bien testé
- Quelqu'un lit le résultat du matin
Une boucle qui brûle du budget
- L'agent a écrit les tests sur lesquels il est jugé
- La condition d'arrêt est « jusqu'à ce que ça semble fini »
- Elle a été lancée sur tout le code dès le premier jour
- Personne ne sait dire ce qu'elle a modifié cette nuit
Les outils de cette vague
Testons-nous cela ?
NonNous ne testons pas les boucles, nous testons ce dont elles dépendent
Une boucle autonome demande des heures, une vraie CI et une base de code que l'ingénieur connaît. Une évaluation de soixante minutes ne peut donc pas la montrer de façon fiable. Ce que nous pouvons observer, ce sont les bases dont une boucle a besoin : l'ingénieur découpe-t-il un ticket flou en morceaux qu'une machine peut vérifier, et vérifie-t-il le résultat au lieu de lui faire confiance parce qu'il compile ?
Maintenant · Vérification
Vague 6 sur 6La vérification est le goulot d'étranglement, et le développement piloté par les specs et les tests le résout
Ce que les équipes ont adopté
Les équipes ajoutent de la revue par IA (CodeRabbit, Greptile, Qodo, Graphite), l'analyse de ce à quoi l'agent a eu accès (Semgrep, Snyk, Socket) et des outils qui montrent la file de revue (Faros, LinearB). Les équipes qui avancent le plus vite changent aussi l'ordre du travail.
Comment le travail a changé
La spec et les tests d'acceptation sont écrits avant que l'agent démarre. La plupart des changements sont donc vérifiés automatiquement, et les équipes ne relisent que ceux qui présentent un risque.
Cinq goulots d'étranglement ont disparu avec la version suivante. Celui-ci reste. Un document de travail de Harvard montre que les entreprises qui ont adopté des agents de code ont ajouté environ 30 % de code en plus, n'ont pas terminé plus de travail et ont mis 49 % de temps en plus à le faire passer en revue. Les outils de revue par IA n'ont pas comblé l'écart.
Quand chaque modification attend qu'un senior la relise, vos seniors deviennent la file d'attente. Le développement piloté par les specs et les tests les en sort : la spec et les tests d'acceptation sont écrits avant que l'agent génère quoi que ce soit. Chaque exécution est donc vérifiée automatiquement par rapport à quelque chose que l'agent ne contrôle pas, et les personnes ne relisent que ce que les tests ne peuvent pas juger.
Où se concentre l'attention
Écrivez d'abord la spec et les tests d'acceptation. Les tests font alors l'essentiel de la vérification, et vos seniors ne relisent que ce que les tests ne peuvent pas juger.
- Résolu
- Développement piloté par les specs et les tests : les vérifications existent avant le code
- Laissé à la vague suivante
- Écrire la spec et les tests une seule fois, avant que l'agent ne tourne
La revue est votre contrainte
- Plus de pull requests fusionnées sans aucune revue
- Les pull requests rédigées par des agents attendent beaucoup plus longtemps avant d'être prises en charge
- Vos seniors sont la file d'attente, et les nouvelles règles l'allongent
- Les agents abandonnent leurs propres pull requests quand le retour n'est pas un contrôle en échec
Vous avez dépassé ce stade
- La spec et les tests existent avant que le code soit généré
- Le vérificateur est indépendant de ce qui a écrit la modification
- La profondeur de revue dépend de ce qu'une modification peut casser
- La file d'attente est vide en fin de semaine
Les outils de cette vague
Revue
Ce que l'agent a atteint
Voir la file d'attente
Testons-nous cela ?
OuiLa vérification pèse le plus lourd dans nos évaluations
La vérification des sorties de l'IA est le critère que nous pondérons le plus pour les ingénieurs AI-native : repérer les API inventées, la logique subtilement fausse et les failles de sécurité avant la mise en production. Le développement piloté par les spécifications est noté dans la même session : nous regardons si l'ingénieur écrit ce que la modification doit faire et comment elle sera vérifiée avant que l'agent ne démarre. Nous observons aussi le jugement selon le niveau de risque. Les ingénieurs QA, eux, vérifient une fonctionnalité qu'ils n'ont pas conçue, avec des tests générés qui passent tous et qui couvrent le mauvais point.
Six pratiques des équipes les plus avancées
Cochez celles que votre équipe applique déjà. À partir de quatre, votre équipe a adopté la façon de travailler, et pas seulement les outils.
Cochez ce que votre équipe fait déjà.
Engineering Leader Benchmark Q4 2026
Découvrez à quel niveau se situe votre équipe
Le benchmark porte sur la façon dont votre équipe travaille avec les agents, vérifie et planifie. Vous obtenez votre score en huit minutes, à côté de celui d'équipes de votre taille dès qu'elles seront assez nombreuses à avoir répondu.
Questions sur le livre blanc
Notre autre livre blanc décrit les deux évaluations que passe chaque ingénieur.
The Next 10X EngineerQuel est le goulot d'étranglement actuel de l'ingénierie logicielle assistée par l'IA ?
La vérification. Les agents de code ont augmenté le volume de code, mais le temps de relecture a augmenté avec lui : un document de travail de Harvard portant sur 718 entreprises relève 30 % de code en plus, aucune hausse significative du travail terminé et 49 % de temps en plus entre la pull request et la fusion.
Dans quel ordre les équipes d'ingénierie ont-elles adopté les outils d'IA ?
En six vagues : la complétion de code comme GitHub Copilot (2022 à 2023), le chat comme ChatGPT et Claude (2023 à 2024), le contexte via le Model Context Protocol et des fichiers comme CLAUDE.md et AGENTS.md (2024 à 2025), les harnais d'agents comme Claude Code et OpenAI Codex (début 2026), les boucles qui exécutent des agents sans validation à chaque tour (mi-2026), et aujourd'hui la revue, l'analyse et le développement piloté par les spécifications et les tests pour vérifier ce que produisent les agents.
Quels outils d'IA une équipe d'ingénierie doit-elle adopter en premier ?
Les outils comptent moins que l'ordre du travail autour d'eux. La plupart des équipes ont déjà la complétion et le chat. L'étape suivante qui rapporte, c'est le contexte : un CLAUDE.md ou AGENTS.md maintenu à jour et des connexions aux tickets et aux schémas. Les agents et les boucles ne rapportent que lorsqu'une équipe écrit la spécification et les tests avant que l'agent ne démarre.
Qu'est-ce que le harness engineering ?
Le harness engineering consiste à concevoir tout ce qui entoure le modèle : la boucle qui l'exécute, les outils qu'il peut appeler, la compaction du contexte, le sandbox, les permissions, les hooks, les sous-agents et l'observabilité. Mitchell Hashimoto l'a nommé en février 2026, avec la formule : agent = modèle + harness.
Quelle est la différence entre le context engineering et le harness engineering ?
Le context engineering décide de ce que le modèle voit, via des fichiers comme CLAUDE.md et AGENTS.md et des protocoles comme MCP. Le harness engineering couvre tout l'environnement d'exécution autour du modèle, y compris ce qu'il a le droit de faire et la façon dont son travail est vérifié.
Miyagami teste-t-il les ingénieurs sur ces compétences ?
Pour la plupart, oui. La vérification, le context engineering, l'orchestration d'outils et l'explication du code généré sont notés dans notre évaluation AI-native, et l'évaluation des fondamentaux se déroule sans outils d'IA. Nous ne testons pas les boucles sans surveillance, car une session de soixante minutes ne permet pas de les observer de façon fiable.
Recevez une shortlist en trois jours
Vous nous indiquez les postes et la stack dans un court formulaire ou lors d'un appel de trente minutes. Sous trois jours ouvrés, vous recevez des ingénieurs seniors nommés à examiner, chacun avec ses deux scorecards, et vous pouvez les recruter sous cinq.
ISO 27001Certifié