Eclairages et perspectives
AI-assisted coding : une transformation qui dépasse le code
Le potentiel est là. Mais il n’attend pas.
GitHub Copilot, Claude Code, Cursor, ces outils affichent des gains de productivité de l’ordre de 40 à 55 % sur la production de code, des cycles de développement raccourcis, une couverture de tests améliorée…
Pourtant, la promesse technologique cache une réalité que beaucoup d’organisations découvrent à leurs dépens : l’outil seul ne change rien. Les résultats sont issus des pratiques, et faire évoluer les pratiques d’équipes de delivery qui ont leur rythme, leurs habitudes et leurs priorités exige un effort structurel que le seul déploiement d’un outil ne suffit pas à déclencher.
L’IA dans la chaîne de développement : un sujet à ne surtout pas restreindre aux Software Engineers
L’erreur la plus répandue consiste à traiter l’AI-Assisted-Coding comme un sujet exclusivement réservé aux Software Engineers : l’outil génère du code, il semble donc naturel de l’adresser à ceux qui en écrivent. Mais cette approche, restrictive, conduit systématiquement à des résultats en deçà du potentiel qu’offre cette technologie.
La valeur de l’IA dans le développement s’étend au-delà des activités de développement. Elle se construit tout au long de la chaîne de valeur, et c’est précisément là que réside le changement structurel. Lorsqu’une organisation adopte une approche « bout en bout », chaque profil de l’équipe adapte son périmètre et son rôle en profondeur.
Le Product manager et le Business Analyst, jusqu’alors cantonnés à la rédaction de spécifications, sont en mesure de construire un prototype avec les utilisateurs, en quasi-temps réel, au plus près du besoin terrain. Le Business Analyst s’appuie sur ce prototype pour le structurer : données, cas limites, spécifications… Autant d’éléments qui permettront aux Software Engineers d’implémenter la solution avec un niveau d’ambiguïté considérablement réduit.
Ces derniers ne se substituent pas à l’IA : ils recentrent leur expertise sur le pilotage des outils, l’arbitrage architectural et la gestion de la complexité. La mobilisation d’agents permet une démultiplication incomparable de la productivité sans compromettre la sécurité et l’intégrité des développements.
Les testeurs, quant à eux, opèrent une transition d’une logique de scripts manuels vers une automatisation augmentée, concentrant leur valeur ajoutée sur la validation métier, la profondeur et le périmètre de tests.
Ce changement de posture ne relève pas de l’ajustements marginaux. Il redéfinit la notion même de contribution au sein d’une équipe de développement augmentée par l’IA. Ne pas embarquer l’ensemble de la chaîne revient non seulement à manquer une opportunité significative, mais aussi à fragiliser l’adoption elle-même, en laissant des pans entiers de l’organisation en dehors de la dynamique.
La formation : condition nécessaire, mais pas suffisante
La réponse instinctive de beaucoup d’organisations face à ce défi est la formation. Des sessions, des modules, des certifications… La formation descendante crée de la connaissance. Elle ne crée pas l’adoption.
L’adoption répond à une logique différente : face à une contrainte de développement, le collaborateur choisit spontanément de recourir à l’outil parce qu’il en a mesuré la valeur dans sa pratique. Ce réflexe ne s’acquiert pas en salle de formation. Il se construit par l’expérience, par les premières victoires concrètes, par les ajustements successifs dans des situations réelles. On apprend à travailler avec l’IA en travaillant avec l’IA, sur de vrais tickets, de vraies user stories, de vrais problèmes issus de la feuille de route de l’équipe.
La formation pose toutefois les fondations nécessaires à l’adoption.
C’est l’expérimentation sur des sujets concrets qui transforme la connaissance en réflexe. Et c’est la coopération au sein des équipes — le fait que PM, BA, Software Engineers et testeurs apprennent ensemble, sur les mêmes challenges — qui garantit une adoption durable plutôt qu’une montée en compétence isolée. Chaque profil doit maîtriser sa partition pour que l’orchestre joue ensemble.
Accélérer l’adoption de l’IA par les équipes : ce qui fonctionne vraiment
La question n’est plus de savoir si les outils sont à la hauteur, mais de comprendre pourquoi l’adoption stagne dans tant d’organisations après les premières semaines, et comment en sortir.
-
Commencer par lever la peur, sans imposer l'outil
La première barrière à l’adoption n’est pas technique : c’est la crainte de devenir moins compétent, ou remplaçable. Gartner l’identifie comme un frein structurel : dans ses travaux sur l’entrenchment organisationnel. Les équipes de développement ne rejettent pas la technologie mais craignent de perdre prise sur leur métier.
Dans ce contexte, il convient d’accepter une idée plus exigeante : déléguer certaines tâches à l’IA, c’est laisser certaines compétences s’atrophier, et c’est délibéré. Toutes ne méritent pas le même degré de vigilance. Certaines constituent des fondations intangibles, le jugement, la capacité à cadrer un problème, la relation aux parties prenantes, qu’aucune délégation ne doit fragiliser. D’autres relèvent de tâches d’exécution dont l’atrophie est non seulement acceptable, mais souhaitable : elles libèrent de la bande passante pour des activités à plus forte valeur ajoutée. C’est cette lecture différenciée qui permet de déléguer avec discernement. L’enjeu n’est pas de tout garder, c’est de savoir ce qui vaut la peine d’être gardé.
Dès lors que la crainte est dissipée et que l’idée est acceptée, l’adoption progresse, non sous la contrainte, mais par conviction.
-
Structurer l'adoption par profil, et non par outil
Proposer le même parcours à l’ensemble des équipes est une erreur fréquente. Chaque profil a ses propres cas d’usage et ses propres points de friction. Ce que les déploiements les plus efficaces ont en commun, c’est une structuration à deux niveaux : bout en bout de la chaîne de développement d’une part (vision horizontale), et par persona d’autre part (vision verticale). Chaque profil doit maîtriser sa propre partition avant que l’équipe puisse jouer ensemble.
-
Miser sur les « champions » autant que sur la formation descendante
La preuve par les pairs est structurante dans l’adoption de l’IA. Les organisations qui structurent un réseau d’ambassadeurs IA, des profils crédibles, issus des équipes elles-mêmes, constatent des taux d’adoption jusqu’à trois à quatre fois supérieurs à ceux d’un déploiement classique. Ces champions sont des praticiens qui testent et partagent des cas d’usage concrets. Citi a ainsi déployé plus de 4 000 ambassadeurs IA à travers 84 pays, atteignant 70 % d’adoption sur l’ensemble de ses effectifs. (Source : Lead with AI)
-
Expérimenter en équipe, sur de vrais sujets
Les équipes n’adoptent pas l’IA sur des cas fictifs — elles l’adoptent en résolvant de vrais tickets, de vraies user stories, de vrais problèmes issus de leur backlog. Le réflexe se construit dans le flux réel du développement, pas en salle. Et il se construit d’autant mieux collectivement : Product Managers, Business Analystes, Software Engineers et testeurs qui progressent ensemble, sur le même sujet, depuis leurs angles respectifs, développent les repères partagés qui garantissent une adoption durable. Une montée en compétence individuelle, sans ancrage collectif produit des îlots d’usage qui ne tiennent pas dans le temps.
-
Mesurer, partager les résultats et montrer l'exemple
L’adoption ne se pérennise que si les équipes voient les résultats. Cela implique des indicateurs définis en amont : vélocité, couverture de tests, temps sur les tâches répétitives, et une transparence régulière sur ce qui fonctionne, y compris quand les données sont décevantes. McKinsey le confirme : le principal obstacle au passage à l’échelle n’est pas la résistance des équipes, mais l’absence de pilotage stratégique côté leadership. (Source : LSE / McKinsey 2025) Ce pilotage passe aussi par l’exemple : les dirigeants qui participent aux sessions d’expérimentation aux côtés de leurs équipes envoient un signal fort : l’IA n’est pas un sujet délégué à l’IT, c’est un enjeu partagé à tous les niveaux.
Conclusion
La technologie est là et les outils sont matures. Ce qui reste à construire dans la plupart des organisations, c’est la capacité à embarquer toute la chaîne de développement, à distinguer ce qui mérite d’être délégué de ce qui doit rester humain, et à créer les conditions d’une expérience réelle plutôt que d’une formation descendante.
L’IA dans le développement n’est pas un projet technique mais bien un projet humain et organisationnel.
