Développeur Augmenté – L'IA au service de la productivité

Tout savoir sur le développeur augmenté par l'IA

Guide complet du développeur augmenté 2026 : agentic coding vs vibe coding, agents IA, MCP, Claude Code, KPI et glossaire des 20 termes essentiels.

Développeur augmenté : quelle réalité pour 2026 ?

2021 - 2026 : De la complétion de code assistée par l'IA aux agents autonomes.

Cinq ans. C'est le temps qui s'est écoulé pour voir le software engineering vivre plusieurs évolutions majeures au fil de la montée en puissance des grands modèles de langage. Flash back.

2021-2023. L'IA influence la complétion de code.

Microsoft introduit la complétion de code basée sur l'IA générative en juin 2021 avec l'outil GitHub Copilot, développé conjointement avec une entreprise alors peu connue du grand public : OpenAI. Basé sur le modèle Codex, GitHub Copilot est intégré en 2022 dans des environnements de développement comme Visual Studio Code, Visual Studio et JetBrains. L'IA générative est évaluée sur des tâches bien délimitées : documentation, génération de scripts, automatisation de tests.

Le développement logiciel s'inscrit alors encore dans une approche traditionnelle. Les développeurs sont aux manettes tout au long du processus et 99% du code est rédigé "à la main". À ce stade, les gains de productivité restent faibles.

2024. L'IA dispose désormais d'IDE dédiés.

L'IA générative prend un autre visage pour les développeurs avec l'arrivée d'environnements complets. Avec ces IDE (Integrated Development Environment) centrés sur l'IA tels que Cursor, les développeurs passent de la complétion de code au code assisté. Le développeur reste le producteur principal du code avec une productivité boostée.

2025. L'IA arrive en ligne de commande.

Troisième vague technologique pour l'intelligence artificielle à destination des développeurs. Avec un changement de paradigme, voire une inversion : dorénavant, l'IA s'impose comme le producteur de code principal tandis que le développeur devient le copilote. Avec des outils emblématiques tels que OpenHands CLI, Claude Code et Gemini CLI, les développeurs conversent en ligne de commande avec l'IA et même les IA dont ils orchestrent le travail en parallèle sur plusieurs tâches.

2026. L'IA se décline sous la forme d'agents autonomes.

Une quatrième génération d'outils IA émerge. Propulsés par les derniers modèles de langage, des agents IA hébergés sur le cloud et capables de travailler en asynchrone font franchir un nouveau cap. À l'instar de Google Jules (animé par Gemini Pro 2.5), ces agents peuvent écrire des tests, corriger des bugs, effectuer du refactoring, générer des changelogs audio, mettre à jour des dépendances… Des essaims de dizaines d'agents peuvent ainsi travailler en parallèle sur un projet sous la supervision du développeur.

Les gains sont colossaux et conduisent Microsoft, Google ou encore Meta à imaginer que la part de code généré par l'IA en 2026 approchera ou dépassera les 50%.

Vibe coding ou agentic coding ?

Chaque révolution a son langage et ses mots. Et celle de l'IA générative appliquée au développement logiciel n'y échappe pas. C'est en février 2025, sur Twitter que Andrej Karpathy, ingénieur réputé en intelligence artificielle (ex-Tesla, cofondateur d'OpenAI), lance l'expression "vibe coding". La notion, très vite relayée dans la communauté tech, dispose de sa page wikipedia dès mars 2025.

Le vibe coding renvoie à une promesse que l'on pourrait résumer ainsi : "code comme tu parles, à l'instinct". Autrement dit, avec le vibe coding, l'humain émet des intentions et laisse l'IA coder. Un peu comme un peintre qui lancerait quelques éclats de peinture sur toile blanche en espérant que la toile comprenne comment ordonner l'ensemble pour parvenir à une œuvre.

Cette mécanique "Prompt-to-Code" est bien incarnée par des outils tels que Bolt ou Lovable, utilisés pour le développement d'apps ou de sites web, en tout cas de leurs prototypes ou de leurs "MVP" (Minimum Viable Product). Car c'est bien là la limite du vibe coding : difficile avec cette approche de passer à l'échelle, de s'inscrire dans une architecture pensée pour tenir la charge, mais aussi pour être versionnée au fil des besoins. Le vibe coding repose sur l'idée que bien exploiter l'IA c'est d'abord savoir prompter là où l'expérience montre que la capacité à structurer une conversation et à assembler du contexte sont bien plus décisifs…

Voilà pourquoi dès le printemps 2025, une autre notion, "l'agentic coding" prend son essor dans l'écosystème du développement logiciel. Une notion directement corrélée à celle "d'agent IA" et "d'IA agentique". Là où le vibe coding s'apparente à une pratique du type "Prompter et laisser faire", l'agentic coding repose sur une collaboration continue entre l'humain et l'IA. Avec le code agentique, le développeur :

• conserve le contrôle et la compréhension de l'architecture
• utilise des agents spécialisés pour des tâches précises
• maintient un contexte cohérent tout au long du développement
• valide systématiquement les outputs avec des critères de qualité

Comme le résume un article de recherche : "Le vibe coding est à l'agentic coding ce que copier un devoir est à étudier avec un tuteur." Pas surprenant donc de voir l'agentic coding supplanter le vibe coding pour donner naissance au développeur augmenté.

Le développeur augmenté : nouvelle espèce ou nouvelle compétence ?

À quoi ressemble le quotidien d'un développeur ? Le rapport DORA 2025 de Google donne de précieuses indications. 90% des développeurs interrogés confirment recourir à l'IA générative dans leur travail et, pour 50% d'entre eux, au moins deux heures par jour. Pour 80%, cette assistance se matérialise par des gains de productivité et pour 59% par une amélioration de la qualité du code.

Se dessine au fil de la lecture ce qu'est fondamentalement, un développeur augmenté : un professionnel qui a appris à orchestrer des agents IA pour démultiplier sa capacité de production. Le ratio réflexion/coding évolue pour donner plus de place à la définition des intentions, à la conception de l'architecture, à la décomposition de la méthode, à la validation des propositions. Un changement de paradigme aussi profond que le passage de l'assembleur aux langages de haut niveau et qui impacte fortement la DevEx (l'expérience développeur).

Aurélien Alienne, Engineering Director Cloud/Data chez SFEIR, résume ainsi son quotidien de développeur augmenté. "Mon workflow s'articule désormais autour de deux espaces : le terminal (CLI) et l'IDE. Avec des outils comme Claude Code ou Gemini CLI, je demande à l'IA de produire le gros œuvre (...). Une fois la structure en place, je bascule dans mon IDE (VS Code, IntelliJ, etc.) pour reprendre la main. C'est l'espace du raffinement, où mon expertise humaine est indispensable : revue de code, débogage, refactoring et audits de sécurité".

Le développeur augmenté ne renvoie pas à une manière unique d'intégrer l'IA générative dans son quotidien. Selon les parcours et les responsabilités, l'IA est exploitée de multiples manières.

• Un profil junior gagne la possibilité d'apprendre plus vite et au fil de l'eau au contact de l'IA. Mais il devra aussi veiller à ne pas devenir trop vite un simple valideur des propositions de l'IA
• Le profil plus expérimenté prend soin d'automatiser ses tâches les plus anciennes et répétitives. Et met son expérience au service d'une revue exigeante du code produit par l'IA tout en accédant à des nouveaux sujets (performance, sécurité)
• Le senior, pour sa part, endosse pleinement dans ce contexte le rôle de gardien du temple. Mentor mais aussi architecte, sa hauteur de vue et son expérience pré-IA lui permettent de garantir la qualité, la sécurité et la maintenabilité à long terme.

Au-delà de l'expérience, ce sont aussi les rôles qui influencent le rapport à l'IA générative.

• Un Tech Lead s'intéresse forcément à l'orchestration muti-équipes, à la gouvernance
• Un responsable DevEx définit l'outillage, les pipelines, les standards
• Un Product Manager creuse les spécifications

S'il n'existe pas un seul archétype de développeur augmenté, il existe bien en revanche des compétences qui, peu à peu, vont s'imposer comme "skills de base" pour tous, que l'on soit développeur, tech lead, architecte…

Les 5 compétences clés du développeur augmenté

Spécifier les besoins, fixer les règles du jeu, orchestrer le travail… Ces termes ne sont pas nouveaux. Mais, appliqués à l'IA générative, ils prennent une dimension - pour ne pas dire une criticité - nouvelle.

Le spec-driven development : l'art de la rigueur en 5 phases

Le spec-driven development (SDD pour les intimes) renvoie à la capacité du développeur à verbaliser de manière précise et structurée. Un travail souvent découpé en 5 étapes qui s'apparentent chacune à un concentré de rigueur.

Etape #1 : Contextualiser

Objectif : donner à l'IA tout ce dont elle a besoin pour comprendre le problème à traiter et l'environnement dans lequel œuvrer. C'est donc ici, et notamment dans un fichier spec.md que sont précisés les objectifs mais aussi leurs critères de validation. L'architecture cible, les dépendances, conventions sont aussi documentées à cette étape dans un fichier distinct (readme.md). Enfin, ce travail de spécification pose aussi les bases des rôles dévolus à chaque agent et des permissions associées (agents.md).

Etape #2 : Planifier

Ce n'est pas encore l'heure de coder. Avant de procéder, une planification s'impose. Etapes, livrables, risques, checklist… L'IA est ici exploitée pour travailler le plan d'actions de manière itérative, parvenir à des étapes resserrées, testables, indépendantes.

Etape #3 : Raisonner

Dernière étape avant de lancer la génération de code, demander à l'IA d'expliciter son raisonnement pour mieux l'explorer, détecter les erreurs de logique et aussi limiter les risques d'hallucination. Une mécanique problème/solution/alternative/risque/test qui permet de sécuriser au mieux la suite.

Etape #4 : Implémenter

La génération de code à proprement parler commence ici, là encore pas en one-shot, mais par itérations successives. Avec un prototype minimal auquel on ajoute les fonctions attendues une à une.

Etape #5 : Valider

Le code généré respecte-t-il les standards fixés en termes de sécurité, couverture fonctionnelle, documentation… ? Cette dernière étape existe pour vérifier cette conformité et passer les différents "quality gates".

Le contexte engineering : l'art de l'efficience

Bien cohabiter avec l'IA ce n'est pas seulement savoir bien lui "parler". C'est aussi être en capacité de gérer avec efficience sa fenêtre contextuelle. Car déborder de cette fenêtre conduit à accroître les risques d'incohérence. D'où le recours à plusieurs techniques :

Le sliding windows

Pour résumer une conversation à ces éléments clés (le contexte initial, les 3 derniers échanges, les décisions actées, les enseignements principaux).

Le semantic chunking

Pour découper les conversations par unités logiques afin d'isoler un module, une fonction, un fichier avec ses dépendances.

Le caching

Pour mettre en cache automatiquement les contextes fréquemment consommés et ainsi économiser les tokens. Une fonction désormais proposée par Claude et Gemini.

Le contexte hiérarchique

Pour structurer le contexte par criticité d'informations afin de n'appeler que les éléments réellement pertinents.

Le Memory store externe

Pour utiliser une base vectorielle afin d'y stocker patterns de code, décisions d'architecture, conversations clés, etc.

L'orchestration multi-agents : l'art du management des agents IA

Nous sommes tous désormais des managers. Avec l'IA, chacun doit en effet apprendre à faire faire. Et pas un seul agent mais à des essaims d'agents qu'il importe d'orchestrer. Un sujet pour lequel Anthropic propose déjà plusieurs patterns :

Le chainage de prompts

La version la plus basique : ici la sortie d'un agent nourrit l'entrée d'un autre. Un mode séquentiel, lisible, prévisible mais… lent.

Le routage

Ici, on ajoute un aiguilleur dans le jeu. A lui d'analyser les requêtes pour les diriger vers l'agent approprié. Un pattern adapté quand les domaines des agents sont bien délimités.

La parallélisation

Objectif : faire travailler les agents sur des tâches indépendantes ou suffisamment découplées pour permettre cette parallélisation. Et ainsi gagner en vélocité.

L'orchestration

Pour les projets complexes, multi-composants, un chef d'orchestre s'impose qui ne se contente pas de router les demandes aux bons agents mais de décomposer un problème afin que les tâches puissent être prises en charge par les agents à sa disposition. Cela tout en maintenant une cohérence globale.

Le duo

Place au binôme qui travaille en cercle vertueux : un agent génère des solutions, l'autre évalue l'adéquation avec le besoin et propose des alternatives ou optimisations. Un pattern qui permet de procéder par petites itérations.

Les agents autonomes

Ce pattern a émergé dans le sillage des nouvelles capacités des solutions qui, comme Claude, peuvent travailler 30 heures en autonomie. Ce qui suppose de laisser les agents décider du séquençage des actions et des outils à activer. Sans surprise, pour éviter toute sortie de route, un gros travail est requis du côté des garde-fous.

On le voit, orchestrer le travail des agents ne se limite pas à les aligner les uns derrière les autres. La nature d'un projet doit soigneusement être analysée pour arbitrer entre les patterns possibles, voire pour les combiner.

Le partage : l'art de la communication

En matière de développement, c'est un principe de vase communicant bien connu : moins on code, plus on doit documenter. Ce qui rehausse le niveau d'exigence à tous les étages.

• Les Pull Requests ne doivent souffrir d'aucune ambiguïté.
• La documentation doit être "vivante". En d'autres termes, les fichiers clés agents.md, spec.md doivent être mis à jour régulièrement. Quant aux ADR (Architecture Decision Record), là aussi, pas de place pour les oublis : les justifications des décisions, les alternatives explorées, les analyses des avantages/inconvénients des scénarios demandent des mises à jour rigoureuses
• Le code review narratif doit être soigné, donc ne pas se limiter au quoi mais détailler le pourquoi.

Ce travail – lourd, il faut le reconnaître – est aussi la condition sine qua non pour faire de l'IA générative un réel levier de productivité sans perdre en qualité et en maintenabilité.

L'analyse intuitive : l'art de l'arbitrage

Dernière corde que le développeur augmenté doit ajouter à son arc, la capacité à écouter ses intuitions jusqu'au bout et à ne pas mettre en sourdine les questions qui affleurent. Par exemple pour…

• comprendre les besoins non-dits d'un client
• évaluer le ROI réel d'une feature qui cristallise peut-être un peu trop l'attention
• naviguer et arbitrer entre les différentes contraintes politiques et organisationnelles

Ces non-dits, ces nuances, ce "jeu dans le jeu", l'IA ne pourra les lire. C'est l'intuition et l'expérience qui doivent ici être aux commandes. Le développeur augmenté est aussi celui qui maîtrise ce qu'il ne faut pas attendre de l'IA.

La collaboration en équipe augmentée

Passer du « développeur augmenté » à l'équipe augmentée consiste à transformer des bonnes pratiques individuelles en standards collectifs. Il ne s'agit donc pas d'additionner des outils, mais de mettre en place un système socio-technique où le contexte, la génération et la validation sont partagés, traçables et reproductibles.

Standards d'équipe : le socle qui rend la génération reproductible

Sans surprise, AGENTS.md est le fichier de chevet de l'équipe : on y définit les rôles d'agents (Frontend, Backend, Tests/QA, Doc/Spec), leurs mandats, leurs entrées/sorties, et des exemples de prompts prêts à l'emploi. À côté, CONTEXT.md (ou README) fixe le périmètre, les objectifs, les contraintes non-fonctionnelles (performance, sécurité, accessibilité), et pointe vers les pipelines CI/CD, les tableaux de bord et les règles de conformité (licences, data boundaries).

Les playbooks décrivent comment formaliser une demande à l'IA, comment valider ce qu'elle retourne, et quand escalader vers un humain. L'enjeu est double : réduire l'ambiguïté et documenter le chemin critique, de la spécification à la pull request, en passant par les tests et les quality gates.

Collaboration augmentée : des contrôles pour combiner vélocité et qualité

Le recours à l'IA au sein d'une équipe augmentée ne remplace pas la collaboration humaine : elle contribue à lui donner un cadre de travail qui tire vers le haut sa performance. Et cela via plusieurs leviers.

• Le pair programming assisté. Un pilote cadre l'objectif et la qualité ; un copilote challenge le raisonnement et la sécurité. Les agents proposent du code, mais l'humain revoit, accepte et documente (mini-ADR, critères).
• La code review augmentée. Les quality gates automatiques (analyse statique, SCA, tests) filtrent les erreurs triviales ; la revue humaine traite la cohérence, l'architecture, la performance et les angles morts.

• Le process CI/CD instrumenté. Avant merge : passage obligatoire par les gates. Après merge : dashboards pour suivre couverture, défauts, vulnérabilités, temps de build, latences, régressions.

Pour quel impact ? Le temps cognitif des développeurs est protégé (moins de bruit en review), les PR sont qualifiées avant d'y consacrer du temps de cerveau humain, les cycles sont accélérés sans compromis sur la sécurité.

Onboarding & diffusion des pratiques : la vitesse devient collective

Une équipe augmentée se reconnaît aussi à sa vitesse d'intégration. L'onboarding sur un projet n'est plus un parcours d'archéologie de tickets et de README plus ou moins mis à jour : on entre par le contexte, on suit le flux agentic, et on manipule vite des cas sûrs (tests, doc, refactors localisés) avant de toucher aux features cœur.

• Parcours guidé. Scénarios d'entrée avec prompts d'exemple, specs minimales et critères de sortie clairs.
• Traçabilité des décisions. ADR courtes, liens vers PR et tests correspondants ; tout est rejouable.
• Rituels d'équipe. Design review agentic (pipeline, gates, métriques), bug autopsy (comment l'IA a-t-elle validé ?), katas sans IA (préserver le craft), ADR lightning (5 minutes/decision).

Résultat, une équipe où la connaissance circule (via les contextes et les traces), où le risque se visualise (via les dashboards) pour un cycle projet qui gagne en vélocité sans perdre en qualité.

Gouvernance, sécurité, conformité : maîtriser la qualité à l'heure du coding agentique

L'accélération ne vaut rien sans confiance. D'où le besoin d'une gouvernance pour transcrire les politiques (sécurité, données, conformité, licences) en mécanismes opérationnels qui s'exécutent dans les outils, les agents et la CI/CD. Objectif : prévenir les incidents, rendre les risques visibles, et prouver que le logiciel livré respecte les règles de l'entreprise.

Guardrails : encoder les règles dans la toolchain

Les guardrails (garde-fous) désignent les contrôles automatisés qui empêchent les comportements indésirables avant qu'ils n'atteignent la production. On y trouve notamment :

• Les listes blanches/noires de modèles, de sources de code et de dépendances
• Les secrets et frontières de données, pour identifier les secrets (API keys, tokens), appliquer l'anonymisation/pseudonymisation des données d'exemples, séparer strictement les zones sensibles (PII, données clients).
• La liste des opérations sensibles à garder sous contrôle humain. Celles qui exigent une double approbation ("4-eyes") pour les actions à risque : changement de schéma, accès prod, modification de règles de sécurité.
• Les règles de journalisation pour garantir la traçabilité par défaut. Avec le "qui/quoi/quand" bien documenté. Modèle/agent utilisé, paramètres, contexte fourni, artefacts générés…

Sécurité active : détecter tôt pour corriger vite

La sécurité n'est pas un tampon de fin de chaîne. Au contraire, c'est une boucle de surveillance continue du code, des dépendances et des environnements. Voici à quoi peut ressembler le "Bouclier Minimum Viable" :

• Une triple analyse
  • SAST (Static Application Security Testing) : injections, failles d'authentification, erreurs cryptographiques.
  • DAST (Dynamic Application Security Testing) : tests d'applications en exécution.
  • SCA (Software Composition Analysis) : vulnérabilités connues, licences incompatibles.
• Un inventaire exact des composants livrés (packages, versions, licences).
• Une modélisation de la menace pour chaque epic sensible avec, à la clé, identification des actifs à protéger et tests de sécurité associés.
• Des métriques et de l'alerting : vulnérabilités ouvertes par sévérité, MTTR (temps moyen de correction), tendances par service ; alertes sur franchissement de seuils.

Conformité & auditabilité : ne pas proclamer mais prouver

La conformité (RGPD, ISO 27001, SOC 2, politiques internes) exige des preuves. Il faut pouvoir reconstituer le film : qui a demandé quoi à l'IA, avec quel contexte, quelles validations, et quel impact.

Ce qui conduit à tracer a minima :

• Les chaînes de bout en bout : ticket → spec (SDD) → générations (prompts/agents) → tests → PR → gates → approbations → déploiement.
• Les décisions d'architecture (Architecture Decisions Record, ADR) : alternatives considérées, critères, raisons du choix.
• Les données sensibles : localisation, transformations (masquage/anonymisation), accès accordés et justifications.
• Les versions : modèles, outils et paramètres.

Gouvernance produit : risque, changement, responsabilité

Le recours à l'IA générative change le profil de risque : plus de productivité, c'est aussi plus d'occasions de se tromper. La gouvernance doit donc s'adapter à cette nouvelle cadence, notamment en rehaussant les exigences. Ce qui suppose :

• Un RACI clair : qui propose, qui valide, qui signe ?
• Un environnement pensé pour le change management : canaux dédiés aux changements sensibles, fenêtres de déploiement, feature flags, rollbacks testés.
• Des niveaux de risque caractérisés (low/medium/high/critical), auxquels correspondent des exigences distinctes, entre autres pour les tests, validations et revues de sécurité.

Sans oublier, des KPI pensés pour faciliter la lecture du flux : taux de PR bloquées par gates, nombre de vulnérabilités résolues par semaine, niveau de couverture des tests, temps moyen de résolution, pourcentage de spécification validées avant build, etc.

L'environnement du développeur augmenté

L'environnement du développeur augmenté se conçoit comme un écosystème articulé autour d'un cycle de travail agentique. Chaque catégorie d'outils occupe une place précise dans ce cycle : certaines accélèrent l'exécution (CLI), d'autres renforcent la lecture et le raffinement (IDE), d'autres encore assurent l'interopérabilité et la gouvernance des capacités (MCP). L'objectif n'est pas l'accumulation d'outils, mais la continuité des flux et la traçabilité des décisions.

Les CLI

Gemini CLI, Claude Code, GitHub Copilot CLI… Les interfaces en ligne de commande constituent le moteur d'exécution de l'environnement augmenté. Elles sont privilégiées pour le heavy lifting : génération en lot, scaffolding, transformations de code récurrentes, migrations, synthèses et création de jeux de tests ou de documentation. Leur intérêt principal réside dans la scriptabilité, le versionning (prompts, contextes, sorties), la reproductibilité et l'intégration fluide aux pipelines CI/CD.

Dans le cycle agentique, les CLI sont précieuses lors des phases de :

• Contextualisation : préparation de corpus, extraction d'information, génération de squelettes.
• Implémentation : production ou refactoring à grande échelle, exécutions répétables.
• Validation : lancement automatisé de suites de tests, de linters et d'analyses statiques.

Les IDE

Qu'ils soient de la génération "IA natifs", comme Cursor ou Windsurf, ou de celle des généralistes avec assistant IA intégré, comme JetBrains, les environnements de développement enrichis par l'IA constituent l'espace de raffinement et de contrôle local. Ils favorisent la compréhension de projets étendus (navigation, recherche sémantique), la co-édition guidée par des objectifs, les refactorings multi-fichiers et la génération ciblée de tests ou de documentation in situ. Leur apport est décisif pour réduire le coût cognitif de lecture, structurer les modifications et maintenir la qualité éditoriale du code et des artefacts.

Dans le cycle agentique, les IDE sont notamment utilisés dans ces phases :

• Raisonnement : élaboration guidée de plans d'implémentation, explicitation de critères d'acceptation.
• Implémentation : itérations courtes, corrections localisées, harmonisation stylistique.
• Validation : génération de tests à partir de spécifications, documentation contextualisée.

Le développeur augmenté sur le terrain : quels KPI et quels gains ?

Adoption et productivité : ce que disent les études

L'IA outille désormais la majorité des développeurs. C'est ce que confirme l'étude Stack Overflow Developer de 2025 : 84 % des répondants déclarent utiliser (ou prévoir de) des outils d'IA tandis que 51 % en font déjà un usage quotidien. Le rapport DORA 2025 de Google recoupe ces ordres de grandeur : 90 % des professionnels du développement y déclarent utiliser l'IA dans leur travail en 2025, soit une hausse de 14 % par rapport à l'année précédente. Et, toujours selon DORA 2025, 65 % confient une forte dépendance à l'IA dans leurs tâches quotidiennes.

Dans le sillage de cette adoption, quels gains de productivité ? Selon la Stack Overflow Developer Survey, 69% des intéressés observent une hausse de productivité sur des tâches ciblées. Du côté de DORA, cette proportion grimpe à 80% avec un impact positif sur la qualité pour 59% des sondés.

Cette transition du développeur au développeur augmenté ne se fait évidemment pas sans questionnement. Seuls 29 % des répondants de l'étude Stack Overflow font confiance à l'exactitude des sorties, tandis que 46 % déclarent explicitement ne pas faire confiance. Un « adoption–trust gap » qui appelle un suivi méthodique de la performance du développeur augmenté mais aussi de sa satisfaction et de son épanouissement.

Mesurer la performance et la satisfaction

La productivité réelle ne se mesure pas en lignes de code ni en prompts. Elle se lit dans un faisceau d'indicateurs et en explorant plusieurs dimensions. Sur ces sujets, les frameworks DORA (élaborés par des chercheurs qui ont rejoint Google) et SPACE (formalisé sous l'égide de Microsoft et Github) apportent des propositions complémentaires :

DORA propose ainsi quatre métriques qui, combinées, permettent de mesurer la vélocité et la stabilité. En d'autres termes, DORA évalue si productivité et qualité progressent de concert. Voici les 4 métriques :

• La fréquence de déploiement (Deployment Frequency) : La fréquence à laquelle le code est déployé en production sur une période donnée, mesurant la rapidité de mise à disposition des fonctionnalités.
• Le délai de mise en production (Lead Time for Changes) : Le temps nécessaire pour qu'un commit passe de la phase de développement à la production, reflétant la réactivité de l'équipe aux besoins du marché.
• Le taux d'échec des changements (Change Failure Rate) : Le pourcentage de déploiements qui entraînent des incidents ou dégradations du service en production, mesurant la qualité et la fiabilité des livraisons.
• Le temps moyen de récupération (Mean Time to Recovery, MTTR) : Le temps moyen nécessaire pour rétablir un service après une défaillance ou un incident, évaluant la capacité de l'équipe à réagir rapidement et minimiser l'impact des problèmes.

SPACE de son côté, s'attache à prendre en compte à la fois des données techniques et des aspects humains en se fondant sur 5 catégories de mesures, à des niveaux individuel et collectif.

• La satisfaction et le bien-être : pour mesurer à quel point les développeurs sont heureux, équilibrés et épanouis dans leur travail.
• La performance : pour évaluer la qualité et la rapidité de livraison du code.
• L'activité : pour quantifier le volume de travail réalisé, comme le temps passé à coder ou le nombre de fonctionnalités complétées.
• La communication et collaboration : pour mesurer l'efficacité des échanges entre développeurs et avec les parties prenantes (qualité des réunions, partage d'information).
• L'efficacité du flux de travail : pour évaluer la fluidité du travail en réduisant interruptions, blocages et nombre de transitions entre tâches.

À chacune de ces catégories peuvent correspondre plusieurs mesures. La satisfaction par exemple peut donner lieu à des enquêtes régulières de satisfaction des développeurs, une mesure du niveau de stress ou encore de l'équilibre vie professionnelle/vie privée. Une certitude : la transformation en cours du développeur en développeur augmenté nécessite une attention continue et globale.