L’IA transforme le métier de développeur, ce que révèle le rapport DORA de Google

L’intelligence artificielle ne se contente plus d’assister ponctuellement les développeurs : elle prend place dans leur environnement de travail quotidien. Génération d’extraits de code, explication d’un programme ancien, rédaction de tests, recherche d’erreurs ou préparation d’une première maquette, les usages se multiplient. Le rapport DORA 2025 de Google invite toutefois à dépasser l’idée d’un outil miraculeux. Pour les équipes logicielles, l’IA agit avant tout comme un amplificateur : elle peut accélérer les bonnes pratiques, mais aussi rendre plus visibles, et parfois plus coûteuses, les faiblesses déjà présentes.

DORA, pour DevOps Research and Assessment, étudie les conditions qui permettent aux organisations de concevoir et de livrer des logiciels de façon fiable. Son rapport annuel observe cette année une adoption rapide des outils d’IA par les professionnels du développement. Il montre aussi pourquoi la question centrale n’est pas seulement « faut-il utiliser l’IA ? », mais plutôt « dans quel cadre l’utiliser, avec quelles données, quels contrôles et quelle organisation ? ».

Une adoption de l’IA devenue massive chez les développeurs

Selon le rapport, environ 90 % des professionnels interrogés prévoient d’intégrer l’IA dans leur travail en 2025. Cette proportion représente une progression de 14,1 % par rapport à 2024, signe d’une accélération rapide de l’adoption. Plus de la moitié des participants déclarent déjà y consacrer plus de deux heures par jour.

Ce mouvement couvre des outils aux fonctions diverses. Certains suggèrent du code à partir d’une instruction en langage courant. D’autres aident à documenter une fonction, résumer des modifications, proposer des tests ou retrouver l’origine probable d’une anomalie. Leur promesse est simple : réduire le temps passé sur des tâches répétitives ou sur la navigation dans une base de code complexe, afin de libérer du temps pour la conception, la vérification et les arbitrages techniques.

Il faut néanmoins lire ces données avec précision. Elles reflètent les déclarations des répondants au rapport, donc leur usage et leur perception des outils. Elles ne signifient pas que chaque ligne de code est désormais produite par une IA, ni que tous les développeurs tirent le même bénéfice de ces assistants. L’adoption peut être très différente d’une équipe à l’autre, selon les règles internes, la maturité technique ou la nature des produits développés.

Productivité et qualité : ce que les développeurs disent gagner

Le résultat le plus marquant est la perception très favorable des utilisateurs. Près de 80 % des répondants estiment que l’IA améliore leur productivité. 59 % constatent également une amélioration de la qualité de leur code. Ces deux chiffres dessinent une évolution importante : l’IA n’est plus seulement vue comme un gadget de démonstration ou un outil réservé aux expérimentations individuelles.

La productivité ne doit pas être réduite à la vitesse de frappe. Un développeur gagne parfois du temps parce qu’il obtient plus vite une explication sur une partie inconnue d’un projet. Il peut aussi partir d’une proposition de test, d’un exemple de requête ou d’une structure de fonction, puis l’adapter à son besoin. Pour des équipes confrontées à des logiciels anciens, volumineux ou peu documentés, cette aide peut raccourcir certaines phases d’exploration.

La qualité est une notion plus exigeante. Un code qui fonctionne dans une démonstration n’est pas nécessairement sûr, maintenable ou adapté aux contraintes d’une entreprise. Il doit être relu, testé, intégré au reste de l’application et surveillé en production. L’amélioration ressentie par 59 % des répondants peut donc traduire plusieurs effets : davantage de temps pour les revues de code, une génération plus systématique de tests, ou une assistance pour repérer des incohérences. Elle ne dispense jamais de la responsabilité humaine sur ce qui est livré.

Pourquoi l’IA amplifie les forces et les fragilités des équipes

Le rapport DORA décrit l’IA comme un amplificateur de performance. Cette formule résume l’un de ses enseignements essentiels. Dans une équipe dotée d’une plateforme technique fiable, de données accessibles, de règles de déploiement claires et d’une culture de collaboration, l’IA peut fluidifier le travail. Elle s’insère dans un système qui sait déjà vérifier, corriger et diffuser les changements de manière maîtrisée.

À l’inverse, une organisation freinée par des systèmes anciens, des validations interminables, des données isolées dans des silos ou une dette technique importante ne règle pas ces problèmes en ajoutant un assistant d’IA. Elle risque plutôt de générer davantage de changements, plus vite, dans un environnement qui peine déjà à les absorber. L’accélération du code produit peut alors déplacer le goulot d’étranglement vers les tests, la sécurité, les équipes d’exploitation ou les processus de validation.

Google distingue sept archétypes d’équipes. À une extrémité figurent les équipes confrontées à des « Foundational challenges », c’est-à-dire à des difficultés structurelles et souvent à une forte pression. À l’autre se trouvent les « Harmonious high-achievers », capables de tirer pleinement parti de leurs pratiques et des outils d’IA. Les archétypes 6 et 7, qui comprennent notamment les « Pragmatic performers » et les « Harmonious high-achievers », représentent environ 40 % des répondants. Ce sont eux qui semblent les mieux placés pour transformer l’adoption de l’IA en résultat durable.

Une cadence de livraison plus élevée, mais des déploiements à surveiller

L’IA facilite notamment le prototypage. Lorsqu’une équipe veut tester une idée, construire une première interface ou explorer une solution technique, elle peut obtenir une base de travail plus vite. Cette accélération permet de confronter plus tôt une hypothèse à des utilisateurs, à un besoin métier ou à une contrainte technique. Elle peut donc rendre les cycles de conception plus courts.

Le rapport souligne cependant une contrepartie : l’augmentation de la cadence de livraison peut s’accompagner d’une instabilité accrue dans les déploiements. C’est un point crucial. Produire plus vite des modifications ne garantit pas qu’elles seront intégrées sans erreur. Plus les changements sont nombreux ou étendus, plus le risque augmente de provoquer des régressions, c’est-à-dire de casser une fonction qui marchait auparavant.

Cette tension n’est pas propre à l’IA, mais l’IA peut l’intensifier. Un assistant est capable de proposer rapidement plusieurs fichiers, de modifier une logique métier ou de suggérer une correction qui paraît plausible. Sans tests automatisés, sans relecture attentive et sans mécanisme de retour arrière, ces changements peuvent se retrouver dans un produit trop tôt.

Le rapport met ainsi en avant le travail en petits lots. Au lieu de demander une refonte massive et de l’intégrer d’un seul coup, l’équipe découpe le problème en changements limités, révisables et testables. Associée au contrôle de version, cette méthode permet d’identifier plus facilement l’origine d’un problème et de revenir à un état antérieur si nécessaire.

Les fondations nécessaires avant de généraliser les assistants

L’un des messages les plus utiles du rapport tient à la préparation de l’organisation. Adopter l’IA ne revient pas seulement à acheter des licences ou à ouvrir l’accès à un outil. Les entreprises doivent définir les conditions dans lesquelles les développeurs pourront s’en servir efficacement et sans créer de risques inutiles.

Une politique d’IA claire pour les équipes

Une politique interne doit préciser ce qui est autorisé, ce qui nécessite une validation et ce qui est interdit. Les règles concernent notamment les responsabilités de chacun, le traitement du code généré et les informations qui peuvent être transmises à un outil externe. Cette clarté évite que chaque développeur improvise ses propres pratiques, avec des niveaux de prudence très variables.

La politique n’a pas vocation à freiner toute expérimentation. Elle doit au contraire rendre l’expérimentation possible dans un cadre compréhensible. Pour cela, les équipes ont besoin de savoir comment signaler une erreur, comment vérifier une proposition générée et à quel moment demander une revue humaine.

Des données accessibles, mais pas dispersées sans contrôle

Le rapport recommande un écosystème de données sain. Pour être utile, l’IA doit pouvoir s’appuyer sur des informations pertinentes, à jour et accessibles aux bonnes personnes. Des données enfermées dans des silos, contradictoires ou mal documentées limitent la qualité des réponses et compliquent le travail des équipes.

Dans le développement logiciel, cela peut concerner la documentation technique, les règles métier, les procédures de déploiement, les bibliothèques internes ou les retours d’incidents. Un assistant ne compense pas l’absence de documentation fiable. Il rend d’autant plus visible le besoin de maintenir cette connaissance collective.

Une plateforme interne pensée comme un produit

Google invite les organisations à investir dans une plateforme interne de qualité, conçue comme un produit et améliorée continuellement. Cette plateforme désigne l’ensemble des outils, services et parcours qui permettent aux développeurs de construire, tester et déployer un logiciel sans devoir résoudre à chaque fois les mêmes problèmes d’infrastructure.

La considérer comme un produit implique d’écouter ses utilisateurs, les développeurs, d’observer les points de friction et d’améliorer l’expérience au fil du temps. C’est un levier essentiel : si l’environnement de livraison est robuste, les gains de vitesse apportés par l’IA ont davantage de chances de se traduire par une amélioration réelle pour les clients.

Le métier de développeur change-t-il vraiment ?

Le rapport dessine moins la disparition du développeur qu’une évolution de son rôle. Lorsque certaines tâches de rédaction, de recherche ou de mise en forme sont accélérées, la valeur du professionnel se déplace davantage vers la compréhension du problème, l’évaluation des compromis et la validation du résultat. Il faut savoir formuler une demande utile, mais surtout détecter une réponse incomplète, inadaptée ou risquée.

Les compétences relationnelles et organisationnelles deviennent également déterminantes. Le développement d’un logiciel est rarement une activité solitaire : il faut clarifier un besoin avec des équipes métier, coordonner les changements, expliquer une décision et prendre en compte les utilisateurs. Une IA peut assister certaines de ces étapes, mais elle ne porte pas la responsabilité du produit final.

Pour les entreprises, l’enjeu est de ne pas mesurer l’IA uniquement à l’aune du nombre de lignes de code produites ou du temps économisé sur une tâche isolée. Les critères les plus pertinents restent la fiabilité du service, la capacité à corriger les incidents, la satisfaction des utilisateurs et la possibilité de faire évoluer le logiciel sans le fragiliser.

Ce qu’il faut surveiller dans les prochains mois

À la date de publication de ce rapport, l’adoption de l’IA dans le développement semble engagée : les outils se banalisent et les développeurs les utilisent déjà de façon régulière. Mais les écarts entre équipes pourraient se creuser. Les organisations les mieux préparées, avec une infrastructure solide et des pratiques de livraison maîtrisées, sont celles qui paraissent les plus susceptibles de convertir l’IA en avantage concret.

Le point de vigilance sera donc moins l’accès aux modèles d’IA que la capacité à les intégrer dans un cycle de travail rigoureux. Politique d’usage, qualité des données, plateforme interne, petits lots, contrôle de version et apprentissage continu forment un ensemble cohérent. Négliger l’un de ces éléments revient à demander à l’IA de résoudre un problème d’organisation qu’elle n’est pas conçue pour régler.

Le rapport DORA appelle enfin à cultiver l’expérimentation et les boucles de retour rapides. Tester de nouveaux usages, observer les effets sur la qualité et ajuster les pratiques est plus utile qu’une généralisation précipitée. Dans le logiciel comme ailleurs, l’IA semble créer le plus de valeur lorsqu’elle est mise au service d’équipes capables d’apprendre, de vérifier et de s’améliorer collectivement.