Intelligence ArtificielleTech

Quand l'IA code : assistants, workflows et adoption dans l'ingénierie logicielle en 2025

Léo GaudezLéo Gaudez•2025-11-03•24 min de lecture
Quand l'IA code : assistants, workflows et adoption dans l'ingénierie logicielle en 2025

Quand l'IA code : assistants, workflows et adoption dans l'ingénierie logicielle en 2025

Retrouver le podcast associé : 🎧 Écouter maintenant 🎧

Imaginez un monde où plus de 80 % des professionnels du développement logiciel utilisent l'intelligence artificielle au quotidien.
Bienvenue en octobre 2025!

Les dernières données issues de la Stack Overflow Developer Survey 2025 montrent que la très grande majorité des développeurs ont déjà adopté des outils d'IA ou prévoient de le faire dans un futur proche, tandis qu'environ un sur deux les utilise quotidiennement pour coder, relire ou documenter du code. Dans le même temps, l'analyse de ces résultats par ShiftMag souligne un paradoxe : près de la moitié des répondants déclarent ne pas faire pleinement confiance aux réponses de l'IA, même s'ils l'utilisent massivement.

Surtout, il faut distinguer deux réalités :

  • d’un côté, la complétion de code “classique” (Copilot, suggestions dans l’IDE, etc.), aujourd’hui quasi omniprésente ;
  • de l’autre, les agents IA capables d’orchestrer des workflows complexes (planification, exécution multi-étapes, modifications du repo, etc.), qui restent encore minoritaires : selon la section « AI Agents » de l’enquête, une minorité de développeurs les utilisent régulièrement, et plus de la moitié ne les ont pas encore intégrés dans leur pratique quotidienne.

Côté impact, les premières études de GitHub sur Copilot ont mesuré des gains spectaculaires : des développeurs accomplissent certaines tâches jusqu’à 55 % plus vite lorsqu’ils utilisent Copilot, tout en rapportant une amélioration de la satisfaction et une baisse de la charge cognitive. Mais en 2025, la révolution ne se mesure plus seulement en lignes de code produites ni en vitesse de frappe. Elle se joue dans le passage d’un “vibe coding” exploratoire — où l’on se contente de “jeter des prompts à l’IA” — à des méthodologies rigoureuses, traçables et reproductibles.

Dans cet article, nous allons :

  • cartographier l’écosystème d’outils qui permet ce changement ;
  • comparer deux acteurs majeurs : Cursor et Claude Code ;
  • décortiquer les nouveaux workflows (Spec-Driven Development, BMAD, etc.) ;
  • et comprendre comment ces pratiques transforment le développeur humain en architecte et chef d'orchestre d'agents autonomes.

1. L’écosystème 2025 : des modèles fondamentaux aux outils de dev

1.1. Les modèles fondamentaux : la couche “invisible” qui propulse les outils

En haut de la pile, on retrouve les fournisseurs de modèles fondamentaux qui alimentent la plupart des outils utilisés par les développeurs :

  • OpenAI avec GPT-5 (août 2025) et ses variantes spécialisées pour le code, intégrés dans de nombreux produits (Copilot, plugins, IDE, etc.).
  • Anthropic, avec les series Opus et Sonnet (4.5 en Septembre 2025) qui se distinguent par un focus assumé sur le raisonnement, l'autonomie et la sécurité, et qui sont au cœur de Claude Code.
  • Google DeepMind avec Gemini 2.5 Pro (Juin 2025), souvent mis en avant pour ses fenêtres de contexte massives (jusqu’à 1 M de tokens dans certains cas d’usage) et son intégration dans Gemini Code Assist et Gemini CLI.
  • xAI, avec Grok 3 (Février 2025) puis Grok 4 très récemment, qui mise sur un rapport performance/prix agressif et un accès en quasi temps réel à certaines sources publiques.

Face à ces offres propriétaires, l’écosystème open-source progresse vite :

  • Llama 3 / 3.1 de Meta, devenus des standards de facto pour de nombreux déploiements auto-hébergés.
  • DeepSeek V3 et V3.1, modèles Mixture-of-Experts très puissants, disponibles via API et, dans certaines variantes, avec des poids réutilisables et une licence orientée vers l’open source.

Ces modèles sont rarement manipulés “à nu” par les développeurs. Ils prennent vie à travers des outils et des workflows.

1.2. Quatre grandes familles d’outils pour les développeurs

Pour les équipes de développement, 2025 s’organise autour de quatre catégories d’outils IA :

  1. Assistants conversationnels & complétion de code

    • Chatbots généralistes (ChatGPT, Claude, Gemini, Grok, etc.) utilisés via le navigateur.
    • Outils de complétion comme GitHub Copilot, Cline, TabNine ou les modèles “Tab” de Cursor.
    • C’est le socle de la première vague : compléter des lignes de code, générer des snippets, expliquer des fonctions.

  2. IDEs IA-natifs

    • Cursor (AI-native IDE basé sur un fork de VS Code, très focalisé sur l’orchestration agentique, la gestion de contexte et l’UX).
    • Windsurf, l’IDE agentique de Cognition (créateur de Devin), aujourd’hui très orienté enterprise et grands monorepos — et désormais propriété de Cognition après une séquence de M&A particulièrement agitée.
    • Kiro, l’IDE agentique de AWS, pensé dès le départ avec un process orienté Spec-Driven Development.
    • Junie, l’agent IA lancé en 2025 par JetBrains, arrive progressivement (Octobre 2025) dans la suite JetBrains : il est déjà disponible dans IntelliJ IDEA Ultimate, PyCharm Pro, WebStorm et GoLand.

    Tous ces IDE partagent une même idée : l’IA n’est plus un plugin, c’est l’architecture centrale de l’outil. Ils gèrent l’indexation de projets entiers, orchestrent plusieurs agents et proposent des modes Plan → Execute pour guider le développement.

  3. CLIs intelligentes (agents pilotés depuis le terminal)

    • Claude Code, de plus en plus utilisé comme CLI agentique (et désormais aussi via une interface web dédiée).
    • Aider, projet open-source de pair programming IA en ligne de commande.
    • OpenCode, CLI multi-modèles open-source bâtie pour le terminal.
    • Gemini CLI, agent open-source de Google qui apporte Gemini dans le terminal, avec une boucle ReAct et le support du Model Context Protocol.
    • GitHub Copilot CLI, désormais en public preview, qui amène le “coding agent” de Copilot directement dans le terminal et se pose explicitement en concurrent de Claude Code, Aider, Codex CLI ou Gemini CLI.

    Ces outils partagent une promesse : “dire ce qu’on veut” au terminal en langage naturel plutôt que se souvenir de commandes ou scripts complexes, tout en pilotant l'ensemble du cycle de développement de manière autonome.

  4. Plateformes IA de bout en bout

    • Replit, Bolt, Lovable ou certains workflows no-code/low-code.
    • L’ambition : prendre un simple prompt et produire une application / prototype fonctionnel (déployée ou non)

  5. Agents asynchrones

    • À ces quatre briques s’ajoute un cinquième mouvement, que nous ne détaillerons pas ici : les agents asynchrones comme ceux les background agents de Cursor, Jules de Google ou encore Devin capables de travailler “en tâche de fond” sur des branches ou des PR.

Note 1 : nous ne parlerons pas non plus dans le détail des services spécialisés “en bout de chaîne” (code review, QA, security review…) comme Qodo, CodeRabbit ou Bugbot, même s’ils participent à la même tendance : industrialiser et fiabiliser l’apport de l’IA à toutes les étapes du cycle de vie logiciel. Note 2 : Cette cartographie d’outils IA pour développeurs n’est pas exhaustive ; elle met en avant les solutions les plus représentatives et utilisées en 2025.

2. Cursor vs Claude Code : deux philosophies, un même objectif

Le duel Cursor vs Claude Code illustre deux approches distinctes du coding assisté par IA :

  • Cursor : une expérience IDE native et fluide, où l'IA s'intègre dans l'éditeur que vous connaissez déjà
  • Claude Code : un agent autonome et versatile, pensé d'abord pour le terminal puis étendu au web

2.1. Cursor : IDE-first

Cursor est un fork de VS Code, pensé comme un IDE IA-natif :

  • Il indexe automatiquement votre codebase (code, docs, configs) et permet de cibler des fichiers, des dossiers ou même de la documentation externe dans les requêtes.
  • Il est multi-modèles : vous pouvez utiliser GPT-5, Claude, Gemini, Grok ou le modèle maison Composer, introduit avec Cursor 2.0 pour optimiser la rapidité des agents.
  • Depuis Octobre 2025, Cursor a introduit une interface multi-agents (jusqu’à huit agents en parallèle dans 2.0) et un mode Plan qui permet de configurer des plans d’implémentation et d’en comparer plusieurs variantes avant de fusionner les diffs.

Côté adoption, Cursor affiche une croissance fulgurante :

  • Plus de 1 million de développeurs l’utilisent, dont plusieurs centaines de milliers d’abonnés payants.
  • L’entreprise a dépassé les 100 M$ d’ARR en un temps record et vise les 200 M$ cette année, avec des valuations qui se chiffrent désormais en milliards.
  • De nombreux retours de terrain (articles, newsletters, études internes) indiquent des gains de productivité significatifs, en particulier pour les équipes qui basculent “tout leur workflow” dans Cursor (coding, refacto, review, doc, etc.).

Configuration : les .mdc et les Hooks

La grande force de Cursor, c’est son système de règles contextuelles :

  • Il repose sur des fichiers .mdc (Markdown Cursor) qui contiennent :
    • des instructions pour l’IA (style, conventions, contraintes d’architecture, bonnes pratiques, etc...) ;
    • des métadonnées qui définissent où et quand appliquer ces règles (par répertoire, type de tâche…).
  • Certaines règles peuvent être globales et toujours actives, d’autres ne se déclenchent que dans un contexte précis (par exemple, uniquement pour les fichiers de tests d’un module) ou passer explicitement dans le prompt.
  • Des hooks permettent de déclencher des comportements spécifiques (par exemple, lancer systématiquement des tests ou des linters après chaque plan d’implémentation).

Résultat : lorsque les équipes investissent dans ces règles, l’ingénierie du contexte (context engineering) devient un véritable levier de qualité et de cohérence.

Côté pricing, Cursor propose :

  • un plan Pro autour de 20 $/mois pour les individuels, avec son pool de crédit ou presque illimité avec son mode auto (Cursor utilise le modèle adapté pour le prompt) ;
  • des plans Team / Enterprise autour de 40 $/utilisateur/mois avec SSO, gouvernance, facturation centralisée, etc.
    Des produits complémentaires comme Bugbot (revue de PR et détection d’erreurs) ou les background agent sont facturés séparément, typiquement ~40 $/utilisateur/mois.

2.2. Claude Code : agent-first, terminal-first, et les sub-agents

Claude Code est l’offre “coding agent” d’Anthropic. Historiquement centrée sur la CLI et le terminal, elle est aussi accessible via une interface web dédiée.

Sa philosophie :

  • Agent-first : Claude Code se comporte comme un collaborateur autonome capable, entre autre, de:
    • naviguer dans des repos entiers ;
    • exécuter des commandes ;
    • lancer des tests ;
    • proposer des refactorings structurés.
  • Terminal-first : l’usage principal reste le terminal, même si une extension VS Code permet d’intégrer Claude Code dans des IDE.
  • Sub-agents : c’est un des points différenciants majeurs :
    • un agent principal délègue à des agents spécialisés (reviewer, test-runner, debugger, refacto, etc.) ;
    • chaque sub-agent dispose de son propre prompt système, de ses outils et d’une fenêtre de contexte adaptée.

En pratique, cela permet des workflows du type :

  • “Prépare un plan d’implémentation détaillé en fonction de cette spec.”
  • “Fais relire ce plan par l’agent architecte.”
  • “Décompose en tâches pour l’agent dev.”
  • “Lance les tests et fais relire les diffs par l’agent reviewer.”

Configuration hiérarchique et gouvernance

Côté configuration, Claude Code adopte une approche plus hiérarchique que Cursor :

  • paramètres globaux (organisation, utilisateur, workspace…) ;
  • overrides par projet puis par module ;
  • configuration des sub-agents (rôles, règles, outils autorisés, etc.).

Cette hiérarchie se marie bien avec les exigences de gouvernance des grandes entreprises (secteurs régulés, contraintes fortes sur la sécurité et la traçabilité) :

  • gestion fine des permissions ;
  • logs détaillés des actions ;
  • intégration avec des outils de contrôle d’accès et de compliance.

Côté pricing (Octobre 2025), Claude Code est aujourd’hui accessible via les abonnements Claude Pro et Claude Max :

  • Pro : autour de 20 $/mois, avec un quota généreux sur les usages standard et l’accès à Claude Code dans la limite d’une fenêtre d’usage glissante de 5 h (grossièrement, une quarantaine de prompts sur Claude ou une dizaine à quelques dizaines de requêtes Claude Code très lourdes).
  • Max : autour de 100 $/mois, pour un usage intensif et des fenêtres d’usage plus larges.

Les quotas d'usage se réinitialisent toutes les 5 heures. En usage intensif, il est possible d'atteindre la limite assez rapidement et de devoir attendre la prochaine fenêtre.

2.3. Interopérabilité, standards émergents et coût total

Passer de Cursor à Claude Code (ou inversement) n’est pas trivial. Les équipes souhaitent :

  • réutiliser leurs prompts, règles, hooks, specs ;
  • éviter de maintenir deux configurations complètement différentes.

Pour cela, plusieurs initiatives émergent :

  • la librairie Ruler (Intellectronica), qui propose un format unifié pour les règles et prompts, et permet de les réutiliser dans les différents outils ;
  • des approches comme AIDD (AI-Driven Development) ou l’AI Dev Kit, qui essayent de standardiser la manière dont les agents interagissent avec le contexte et les spécifications.

Cela reste encore expérimental : ces standards comme AGENTS.md couvrent bien les cas simples, mais dès qu’on exploite des features très spécifiques (sub-agents Claude Code, .mdc Cursor, etc.), il faut encore adapter manuellement.

Enfin, le coût total joue un rôle stratégique :

  • la plupart de ces outils démarrent autour de 20 $/mois par utilisateur pour un usage individuel,
  • mais il faut ajouter :
    • les surcoûts d’API (modèles frontier, ou usage intensif agentique) ;
    • les add-ons (Bugbot, outils de qualité, etc.) ;
    • et éventuellement les coûts d’infrastructure si l’on self-hoste des modèles open-source.

Beaucoup d’équipes finissent donc, par contrainte budgétaire et opérationnelle, par standardiser sur un outil principal (par exemple Cursor ou Windsurf) tout en gardant un second outil (Claude Code, Gemini) pour des cas d’usage spécifiques.

3. Nouveaux workflows : du vibe coding au Spec-Driven Development et à BMAD

Les méthodologies agiles “classiques” (PRD, epics, user stories, critères d’acceptation…) ne disparaissent pas avec l’IA. Au contraire : l’IA fonctionne mieux lorsqu’elle est encadrée par des artefacts clairs et structurés.

3.1. Vibe coding vs développement structuré

On parle de “vibe coding” lorsqu’un développeur :

  • donne à l’IA des objectifs assez larges (“fais-moi un dashboard analytics”, “réécris ce service en plus propre”, etc.) ;
  • laisse l’agent explorer, générer du code, exécuter des commandes et itérer ;
  • se concentre davantage sur le résultat observable (tests qui passent, appli qui tourne) que sur la compréhension fine du code.

Cette pratique, popularisée par certaines figures de la communauté et largement étudiée dans les médias tech, a des avantages :

  • rapidité de prototypage ;
  • réduction de la barrière à l’entrée pour des non-experts ;
  • capacité à explorer plusieurs pistes en parallèle.

Mais les études et retours d’expérience pointent aussi des risques :

  • architecture fragile, dette technique cachée, peu évolutif ;
  • bugs subtils et problèmes de sécurité difficiles à détecter ;
  • difficulté à maintenir le code lorsque l’équipe change.

Des articles comme “Senior developers are all in on vibe coding, but junior staff lack the experience to spot critical flaws” (ITPro) ou des analyses récentes sur l’usage quasi systématique de l’IA dans certaines équipes montrent que les développeurs expérimentés tirent mieux parti du vibe coding, mais que les juniors peuvent se faire piéger par du code “qui marche” mais violerait des contraintes essentielles (performance, sécurité, règles métier…).

D’où la montée en puissance de méthodes comme le Spec-Driven Development (SDD) ou BMAD, qui cherchent à canaliser la puissance des agents au lieu de la subir.

3.2. Le Spec-Driven Development (SDD) et GitHub Spec Kit

Le Spec-Driven Development part d’une idée simple :

Avant de demander à l’IA d’écrire du code, écrivons une spécification structurée qui deviendra la source de vérité – pour les humains et les agents IA.

GitHub a matérialisé cette approche avec GitHub Spec Kit, un toolkit open-source conçu pour fonctionner avec Copilot, Claude Code, Cursor, Kiro, etc.

Le flux “canonique” se décompose en quatre phases :

  1. Specify

    • On capture l’intention dans un document de spec :
      • besoins métier, objectifs ;
      • contraintes techniques ;
      • critères d’acceptation.
    • Avec Spec Kit, on peut utiliser des commandes comme /specify dans son agent ou l’outil en ligne de commande specify pour transformer un brief en spec structurée (souvent au format Markdown).

  2. Plan

    • À partir de la spec et du contexte (stack, architecture, contraintes non fonctionnelles…), l’IA génère un plan d’implémentation :
      • étapes successives ;
      • dépendances ;
      • risques identifiés.
    • Le développeur itère avec l’IA jusqu’à ce que le plan soit satisfaisant. L’idée est de figer un chemin d’exécution avant d’écrire la moindre ligne de code.

  3. Tasks

    • Le plan est ensuite "atomisé" en tâches actionnables et testables :
      • idéalement de la taille d’une PR cohérente ;
      • référençant la spec et le plan ;
      • contenant tout le contexte nécessaire pour être implémentées par un agent (ou un junior).
    • Certaines implémentations (Spec Kit, Kiro, etc.) produisent directement des fichiers de tâches (YAML/Markdown) que les agents peuvent consommer.

  4. Implement

    • L’IA exécute les tâches : génération de code, tests, docs.
    • L’humain reste dans la boucle :
      • review des diffs ;
      • validation ou ajustement du plan ;
      • décisions d’architecture.

Ce flux SDD peut paraître lourd pour de petites évolutions. En pratique, les équipes adaptent :

  • pour des petites évolutions isolées comme changement de wording, amélioration du design, on reste souvent dans un cycle plus “vibe + review” ;
  • pour une feature structurante ou des refactors profonds, le SDD apporte de la clarté et de la traçabilité.

3.3. BMAD : orchestrer des agents spécialisés avec des Story Files

L'autre approche structurée en vogue est la BMAD Method (souvent déclinée sous la forme d'un framework open-source).

L’idée : formaliser une équipe multi-agents représentant différents rôles humains du cycle de développement :

  • Analyste
  • Product Manager
  • Architecte
  • Développeur
  • Scrum Master
  • etc.

BMAD propose un système à 5 niveaux (0-4) qui adapte la profondeur de planning et de documentation selon la complexité

Contrairement à une méthode rigide, BMAD "dose" automatiquement le niveau de planification, documentation et orchestration nécessaire.

Une méthodologie en 4 phases

  1. Analysis (optionnelle) : brainstorming, recherche, product briefs
  2. Planning (requise) : génération de PRD/tech-spec/GDD adapté au niveau
  3. Solutioning : décisions d'architecture et design
  4. Implementation (itérative) : développement story-centric avec contexte "just-in-time"

12 agents spécialisés orchestrés

Au-delà des rôles classiques (PM, Analyst, Architect, Developer, Test Architect, UX Designer), BMAD intègre :

  • Un BMad Master qui orchestre l'ensemble
  • Des agents spécialisés pour le game dev (Game Designer, Game Developer, Game Architect)
  • Un agent dédié à la documentation

Chaque agent n'intervient que lorsque c'est nécessaire selon le niveau de complexité.

Gestion intelligente du contexte

BMAD résout le problème de surcharge contextuelle via :

  • Document sharding : pour les projets Level 3-4, les workflows ne chargent que les sections pertinentes (réduction de 90%+ des tokens)
  • Contexte just-in-time : chaque agent reçoit uniquement ce dont il a besoin pour sa tâche
  • Story-centric implementation : en Phase 4, on travaille story par story avec le contexte ciblé

Distinction importante : CORE vs Method

  • BMAD-CORE : le framework sous-jacent (orchestration d'agents, workflows, architecture modulaire)
  • BMM (BMad Method Module) : le module de développement logiciel avec ses 12 agents et 34 workflows
  • BMB (BMad Builder) : pour créer vos propres agents/workflows personnalisés
  • CIS (Creative Intelligence) : workflows de facilitation créative

En résumé :

  • Spec Kit / SDD : pipeline structuré (spec → plan → tâches → implémentation) qui permet de démarrer rapidement et garde l'humain aux commandes
  • BMAD : orchestration multi-agents avec formalisation de rôles (analyste, architecte, dev…) et Story Files qui embarquent tout le contexte utile (objectifs, contraintes, règles d'archi, critères d'acceptation)

Avantages et contraintes :

Spec KitBMAD
SetupRapide à mettre en placePlus long avant de déléguer
FlexibilitéMoins contraignantPlan d'exécution très figé
TraçabilitéBonne, pilotée humainExcellente, handoffs clairs
ItérationsPeut nécessiter des allers-retoursMoins d'allers-retours quand les exigences évoluent

À noter : Chaque équipe peut adapter ces méthodes en fonction de la complexité — préconfigurer les étapes, les redécouper ou en ajouter. On peut même combiner les approches selon les phases du projet. On peut utiliser ces méthodes dans la majorité des outils et exécuter certaines phases dans des outils différents (gemini gems puis Claude Code par exemple).

Optimisation des coûts : Les deux méthodes permettent d'utiliser des modèles différents selon la phase :

  • Modèles "heavy reasoning" (plus lents, plus chers) pour l'analyse et les décisions d'architecture
  • Modèles plus rapides et économiques pour les tâches d'implémentation très ciblées

L'objectif commun : éliminer la perte de contexte ou la surcharge de contexte, et mieux diriger l'IA pour réduire les erreurs.

4. Adoption, impact et nouveau rôle du développeur

4.1. Adoption massive, confiance mitigée

Comme évoqué en introduction, les chiffres 2025 sont parlants :

  • > 80 % des développeurs déclarent utiliser des outils d’IA ou prévoir de le faire dans leurs workflows ;
  • environ un sur deux les utilise tous les jours ;
  • mais près de la moitié indique ne pas leur faire confiance.

Côté agents, les données de la section “AI Agents” de la même enquête (StackOverflow) montrent que :

  • une minorité significative (autour d’un tiers) utilise déjà des agents au moins une fois par mois ;
  • plus de la moitié restent cantonnés à des outils plus simples (complétion, chat ponctuel) ou n’utilisent pas d’IA du tout.

Ce décalage illustre bien l’état du marché : les outils sont là, puissants, parfois impressionnants – mais les organisations n’ont pas encore toutes la culture, les garde-fous et les workflows pour en tirer un bénéfice systématique.

4.2. Cursor vs Claude Code dans les entreprises

On observe globalement une polarisation des usages :

  • Startups, indie hackers, petites équipes produit

    • forte adoption de Cursor et parfois de Windsurf, pour leur vitesse, leur UX et leur intégration profonde au flux quotidien de développement ;
    • usage courant du vibe coding, souvent rattrapé par des outils comme CodeRabbit et les code review humaines

  • Grandes entreprises, secteurs régulés (finance, santé, cybersécurité, secteur public…)

    • intérêt marqué pour Claude Code (log d’exécution, gouvernance, gestion des permissions, intégration à des environnements verrouillés, extension VS Code native) ;
    • Gemini CLI pour développeurs Google Cloud/Workspace cherchant l'intégration native avec l'écosystème Google.

  • Approches structurées émergentes

    • Kiro (AWS, juillet 2025) : pionnier du spec-driven development avec requirements.md/design.md/tasks.md basés sur EARS, visant à remplacer le "vibe coding" par une planification formelle ;
    • JetBrains Junie : agent agentic dans les IDEs JetBrains (IntelliJ, PyCharm) avec 60.8% sur SWEBench, focus sur transparence et contrôle développeur.

En pratique, la frontière n’est pas nette :

  • Cursor renforce ses garde-fous (privacy mode, contrôle fin de la data envoyée aux modèles, hooks de sécurité, Code review intégré, Bugbot pour code review automatisée) ;
  • Claude Code améliore son intégration dans les IDE (extension VS Code, onglet “Code” dans l’interface web, meilleure UX pour gérer les sessions longues) ;
  • d’autres IDE comme Kiro poussent des approches orientées Spec-First, très proches des workflows SDD.

4.3. Le nouveau rôle du développeur

Dans ce contexte, le développeur ne disparaît pas – mais son rôle change profondément.

Plutôt que de produire du code ligne par ligne, il devient :

  • chef d’orchestre d’intelligence logicielle :

    • Il comprend les besoins métiers et structure les specs ;
    • Choisit et s'adapte aux outils (Cursor, Claude Code, Kiro, Gemini CLI…) ;
    • Configure les règles, prompts, hooks, la CI/CD ;
    • Supervise les plans et les exécutions.

  • responsable de l’alignement produit / technique :

    • il veille à ce que le code généré par les agents respecte les contraintes métier, de sécurité, de performance ;
    • il arbitre entre expérimentations rapides (vibe coding) et industrialisation (SDD, BMAD).

  • gardien de la qualité :

    • il reste responsable du code, de la review, des tests, de la maintenabilité ;
    • il ne se contente pas de “patcher” du code généré sans se soucier de l’architecture globale.

Les métriques de performance évoluent elles aussi :

  • on se détache du volume de code produit comme indicateur principal ;
  • on se recentre sur :
    • la fréquence de déploiement ;
    • le lead time entre le commit et la mise en production ;
    • le taux d’échec en production ;
    • le temps moyen de restauration en cas d’incident ;
    • et, surtout, l’impact produit / business réel.

Des travaux comme ceux du livre Accelerate ou des métriques DORA restent très pertinents dans ce monde où l’IA "code" pour les devs : ils rappellent que ce ne sont pas la quantité de code ni le nombre de réunions qui font la performance d’une équipe, mais sa capacité à livrer fréquemment, de manière fiable et avec un feedback rapide.

5. Conclusion : coder avec discernement

L’année 2025 marque la fin de la “phase gadget” et l’entrée dans une ère de développement logiciel structurée par l’IA.

  • Les outils comme Cursor, Claude Code, Windsurf ou Kiro ne sont plus de simples assistants : ce sont des environnements complets qui orchestrent des agents, gèrent le contexte et modifient directement le code.
  • Les méthodologies comme le Spec-Driven Development (avec GitHub Spec Kit) ou la BMAD Method donnent un cadre clair, traçable et collaboratif à cette collaboration humain-IA.
  • Les entreprises qui réussissent ne sont pas celles qui “automatisent tout”, mais celles qui savent concevoir des workflows robustes, alignés avec leurs contraintes et leur stratégie produit.

Le développeur, lui, devient chef d’orchestre :

  • il conçoit les workflows,
  • valide les plans,
  • garde la main sur les décisions structurantes.

La clé reste profondément humaine : rigueur, curiosité, sens du produit, capacité à construire de bons workflows.
L’avenir du code se jouera dans cette alliance entre créativité et contrôle, automatisation et discernement.

Vous pouvez aussi suivre les contenus associés sur LinkedIn, ou me contacter directement via [email protected] pour échanger autour de sujets Tech ou Produit.

Par Léo Gaudez
Explorons ensemble le futur du développement piloté par l’intelligence artificielle.

🔗 Podcast associé

🎧 Épisode : Quand l'IA code — assistants, workflows et adoption dans l'ingénierie logicielle en 2025

📚 Ressources

Sources principales de l’épisode

Ressources complémentaires (écosystème & workflows)

(Liste non exhaustive — pour une veille continue, se référer aux changelogs officiels des outils et aux blogs des éditeurs.)

← Retour aux ressources