# L'IA en ingénierie : quels outils, et quand | Miyagami > Livre blanc interactif de Bo Wesdorp : quatre ans d'IA en ingénierie, de Copilot aux boucles d'agents, et ce que chaque étape a changé. Source: https://www.miyagami.com/fr/resources/whitepapers/how-ai-changed-engineering 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. Suivre le parcours 1. 1 Complétion 2. 2 Chat 3. 3 Contexte 4. 4 Harness 5. 5 Boucle 6. 6 Vérification 7. → Que faire Introduction Bo Wesdorp **Bo Wesdorp** Cofondateur et CTO, Miyagami 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. **80 à 90 %** du code de production de nos projets sort d'un modèle **10 à 4** ingénieurs sur un projet qui en nécessitait dix en 2024 **6** vagues d'outils d'IA en quatre ans Le parcours d'adoption ## 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 à 2023Complétion *GitHub Copilot* *T**Tabnine* *Amazon CodeWhisperer* *Complétion de ligne entière JetBrains* *K**Kite* 2023 à 2024Chat *ChatGPT* *Claude* *GitHub Copilot Chat* *Cursor* 2024 à 2025Contexte *Model Context Protocol* *CLAUDE.md* *A**AGENTS.md* *.cursorrules* *A**Aider* Début 2026Harness *Claude Code* *OpenAI Codex* *LangChain Deep Agents* *L**Langfuse* *Braintrust* Mi-2026Loop *Claude Code /loop* *Codex goals* *GitHub Copilot coding agent* *O**OpenClaw* *GitHub Actions* Aujourd’huiVérification *CodeRabbit* *Greptile* *Qodo* *Graphite* *S**Semgrep* 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 Lire le chapitre 01 2022 à 2023 · Complétion Vague 1 sur 6 ## La 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 [**GitHub Copilot**](https://github.com/features/copilot) [*T* **Tabnine**](https://www.tabnine.com/) [**Amazon CodeWhisperer** devenu Amazon Q Developer](https://aws.amazon.com/q/developer/) [**JetBrains full-line completion**](https://www.jetbrains.com/help/idea/full-line-code-completion.html) *K* **Kite** arrêté en 2022, avant que les modèles ne soient assez bons Testons-nous cela ? En partie Nous 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. [Compréhension techniqueFundamentals scorecard](https://www.miyagami.com/fr/how-we-vet#fundamentals)[DébogageFundamentals scorecard](https://www.miyagami.com/fr/how-we-vet#fundamentals) Recruter sur ce critère [Ingénieurs full-stack](https://www.miyagami.com/fr/hire/full-stack-engineers) [Ingénieurs frontend](https://www.miyagami.com/fr/hire/frontend-engineers) 02 2023 à 2024 · Chat Vague 2 sur 6 ## Le 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 [**19% plus lent** Dans un essai de 2025, des développeurs expérimentés étaient 19% plus lents avec des outils d'IA, alors qu'ils se croyaient 20% plus rapides. METR, juillet 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) Les outils de cette vague [**ChatGPT**](https://chatgpt.com/) [**Claude**](https://claude.ai/) [**GitHub Copilot Chat**](https://github.com/features/copilot) [**Cursor** a clos cette période en laissant le modèle lire l'ensemble du dépôt](https://cursor.com/) Testons-nous cela ? Oui Nous 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. [Vérification des sorties de l'IAAI-native scorecard](https://www.miyagami.com/fr/how-we-vet#ai-native)[Prompt and context engineeringAI-native scorecard](https://www.miyagami.com/fr/how-we-vet#ai-native) Recruter sur ce critère [AI-native engineers](https://www.miyagami.com/fr/hire/ai-native-engineers) [Ingénieurs full-stack](https://www.miyagami.com/fr/hire/full-stack-engineers) 03 2024 à 2025 · Contexte Vague 3 sur 6 ## Le 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é ». **Fichiers de contexte** 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. **Model Context Protocol** 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 [**Model Context Protocol**](https://modelcontextprotocol.io/) [**CLAUDE.md**](https://code.claude.com/docs/en/memory) [*A* **AGENTS.md**](https://agents.md/) [**.cursorrules**](https://cursor.com/docs/context/rules) [*A* **Aider** a cartographié des dépôts plus grands que la fenêtre de contexte](https://aider.chat/) [**Cline**](https://cline.bot/) [**Windsurf**](https://windsurf.com/) Testons-nous cela ? Oui Nous é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. [Prompt and context engineeringAI-native scorecard](https://www.miyagami.com/fr/how-we-vet#ai-native)[Spec-driven developmentAI-native scorecard](https://www.miyagami.com/fr/how-we-vet#ai-native) Recruter sur ce critère [AI-native engineers](https://www.miyagami.com/fr/hire/ai-native-engineers) [Ingénieurs d'intégration LLM](https://www.miyagami.com/fr/hire/llm-integration-engineers) 04 Début 2026 · Harness Vague 4 sur 6 ## Le 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 [**Claude Code** hooks, skills et sous-agents](https://code.claude.com/docs) [**OpenAI Codex**](https://developers.openai.com/codex) [**LangChain Deep Agents**](https://docs.langchain.com/oss/python/deepagents/overview) [*L* **Langfuse** voir ce que l'agent a fait](https://langfuse.com/) [**Braintrust**](https://www.braintrust.dev/) Testons-nous cela ? En partie Nous 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. [Orchestration des outilsAI-native scorecard](https://www.miyagami.com/fr/how-we-vet#ai-native)[Hygiène du changement de contexteAI-native scorecard](https://www.miyagami.com/fr/how-we-vet#ai-native) Recruter sur ce critère [AI-native engineers](https://www.miyagami.com/fr/hire/ai-native-engineers) [Ingénieurs DevOps](https://www.miyagami.com/fr/hire/devops-engineers) [Ingénieurs IA](https://www.miyagami.com/fr/hire/ai-engineers) 05 Mi-2026 · Boucle Vague 5 sur 6 ## La 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 [**Claude Code /loop**](https://code.claude.com/docs/en/scheduled-tasks) [**Codex goals**](https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex) [**GitHub Copilot coding agent**](https://docs.github.com/en/copilot/concepts/agents/coding-agent) [*O* **OpenClaw**](https://github.com/openclaw/openclaw) [**GitHub Actions** la CI comme déclencheur et vérificateur](https://github.com/features/actions) Testons-nous cela ? Non Nous 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 ? [Développement piloté par la specScorecard AI-native](https://www.miyagami.com/fr/how-we-vet#ai-native)[Vérification des sorties de l'IAScorecard AI-native](https://www.miyagami.com/fr/how-we-vet#ai-native) Recruter sur ce critère [AI-native engineers](https://www.miyagami.com/fr/hire/ai-native-engineers) [Ingénieurs DevOps](https://www.miyagami.com/fr/hire/devops-engineers) 06 Maintenant · Vérification Vague 6 sur 6 ## La 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 [**+30%** de code en plus dans les entreprises qui ont adopté des agents de code, sans hausse statistiquement significative du travail terminé Chen et Stratton, Harvard, 2026](https://fion.ac/jellyfish.pdf) [**+49%** de délai en plus entre la pull request et la fusion après l'arrivée des agents Chen et Stratton, Harvard, 2026](https://fion.ac/jellyfish.pdf) [**+31%** de pull requests fusionnées en plus sans aucune revue, humaine ou agentique, avec une forte adoption de l'IA Faros AI, 2026](https://www.faros.ai/research/ai-acceleration-whiplash) [**5.3x** d'attente en plus pour les pull requests rédigées par des agents avant qu'un relecteur s'en saisisse LinearB, 2026](https://linearb.io/library/engineering-benchmarks-and-research) 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 [**CodeRabbit**](https://www.coderabbit.ai/) [**Greptile**](https://www.greptile.com/) [**Qodo**](https://www.qodo.ai/) [**Graphite**](https://graphite.dev/) Ce que l'agent a atteint [*S* **Semgrep**](https://semgrep.dev/) [**Snyk**](https://snyk.io/) [**Socket**](https://socket.dev/) Voir la file d'attente [*F* **Faros**](https://www.faros.ai/) [*L* **LinearB**](https://linearb.io/) Testons-nous cela ? Oui La 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. [Vérification des sorties de l'IAScorecard AI-native](https://www.miyagami.com/fr/how-we-vet#ai-native)[Développement piloté par les spécificationsScorecard AI-native](https://www.miyagami.com/fr/how-we-vet#ai-native)[DébogageScorecard des fondamentaux](https://www.miyagami.com/fr/how-we-vet#fundamentals) Recruter sur ce critère [AI-native engineers](https://www.miyagami.com/fr/hire/ai-native-engineers) [Ingénieurs QA](https://www.miyagami.com/fr/hire/qa-engineers) Où en est votre équipe ## 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. **0** sur 6 en place Cochez ce que votre équipe fait déjà. 1. 1 **La spécification avant le code** Écrivez ce que la modification doit faire, ce qu'elle ne doit pas casser et quels modules elle touche, puis générez à partir de ce cadre. Un ticket vague confié à un agent produit un travail assuré, bâti sur une supposition. 2. 2 **Les tests avant la fonctionnalité** Si le même modèle écrit le code et les tests dans une seule session, un pipeline au vert signifie que le modèle est cohérent avec lui-même. Cela ne veut pas dire que le code est correct. 3. 3 **Un vérificateur indépendant** Un contrôle de types, un budget de performance, un test de contrat géré par un autre service. Un élément que la chose vérifiée ne contrôle pas. 4. 4 **Une revue selon le périmètre d'impact** Une modification de texte et une migration de schéma ne doivent pas faire la queue l'une derrière l'autre. Décidez quelles catégories exigent toujours une relecture humaine complète et allégez la revue pour le reste. 5. 5 **Un responsable nommé par dépôt** Le fichier de contexte relève de son périmètre et il a le pouvoir de dire non. Un dépôt qui reçoit des contributions à la vitesse des agents, sans responsable, gonfle en quelques semaines. 6. 6 **Mesurer la charge de vérification** Le pourcentage de code écrit par l'IA ne vous apprend rien. La quantité de changements que votre équipe peut lire, exécuter et garantir en une semaine fixe votre vrai plafond. 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. [Faire le benchmark](https://www.miyagami.com/fr/resources/benchmarks/engineering-leader-q4-2026) Le rapport Engineering Leader Benchmark Q4 2026 FAQ ## Questions sur le livre blanc Notre autre livre blanc décrit les deux évaluations que passe chaque ingénieur. [The Next 10X Engineer](https://www.miyagami.com/fr/resources/whitepapers/the-next-10x-engineer) Quel 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. Parlons-en ## 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. [Obtenir une liste restreinte](https://www.miyagami.com/fr/shortlist) Évalué sur **Clutch** 42 avis [ISO 27001 Certifié](https://trust.miyagami.com/) Réserver trente minutes avec Dale Le calendrier est fourni par HubSpot, qui dépose ses propres cookies. Chargez-le ici, ou réservez sur la page HubSpot. [Ouvrir la page de réservation](https://sales.miyagami.com/meetings/dwesdorp)