Copilot l’a écrit, mais qui en est propriétaire ? L’écart de gouvernance que les équipes d’ingénierie peuvent négliger

Un ingénieur ouvre Copilot pour aider à rédiger du code pour le site d’un client. En quelques secondes, il reçoit du code qui, auparavant, aurait nécessité beaucoup plus de temps à écrire manuellement. Pour de nombreux développeurs web et entreprises qui optimisent leurs sites, il est normal de se demander: ce code est‑il fiable ? Est‑il sécurisé ? Doit‑il être revu avant d’être mis en œuvre ? Toutes ces questions relèvent d’une même interrogation: qui sera tenu responsable du codage assisté par l’IA ? Et, surtout, qui possède le gain de productivité ?

Si l’IA permet à une équipe d’ingénierie d’accomplir davantage de travail dans le même laps de temps, tout le monde peut tirer parti de cette valeur économique. Cela peut être le développeur qui gagne du temps, l’employeur qui obtient plus de valeur grâce aux heures économisées, ou le client qui reçoit ce pour quoi il a payé avec du temps restant. Quelle que soit la façon dont le temps économisé profite, la question centrale reste la gouvernance et la tarification du travail.

AI and Coding is Becoming Unavoidable

Les outils de codage IA gagnent rapidement du terrain et s’imposent dans le développement grand public. Selon le 2025 Stack Overflow Developer Survey, 84 % des répondants utilisaient ou prévoyaient d’utiliser des outils d’IA dans leur processus de développement.

Bien que l’intégration de l’IA dans les flux de travail des développeurs web devienne plus courante, il subsiste des réticences quant à sa fiabilité. La même enquête a révélé que 46 % des participants n’avaient pas pleinement confiance dans la précision des résultats de l’IA, et environ 66 % ont exprimé leur frustration face à des solutions d’IA « presque correctes, mais pas tout à fait ».

Le débat autour du codage IA qui se dessine porte davantage sur sa fiabilité que sur la création de valeur et sur la responsabilité d’en assurer le bon usage.

AI Is Breaking the Relationship Between Hours and Output

La rémunération du développement logiciel reposait toujours sur l’hypothèse selon laquelle la production d’ingénierie était étroitement liée à l’effort fourni. L’IA générative complique désormais cette équation.

Une expérience contrôlée impliquant 95 développeurs a montré que les participants disposant de GitHub Copilot ont terminé une tâche spécifique de serveur HTTP JavaScript 55,8 % plus rapidement que ceux qui n’y avaient pas accès.

Cela montre que l’IA peut accélérer le développement, potentiellement sans sacrifier la qualité. Mais ces chiffres ne sont valables que parce que l’expérience portait sur une tâche de programmation très précise. Même si la tâche a été accomplie plus rapidement, cela ne signifie pas que Copilot rend une organisation d’ingénierie 55,8 % plus productive dans son ensemble.

Une autre étude illustre ce propos. Un essai impliquant 96 ingénieurs logiciels à plein temps chez Google a révélé que les développeurs utilisant l’IA ont terminé une tâche de niveau entreprise en environ 96 minutes, contre 114 minutes pour ceux qui n’en disposaient pas. L’estimation ajustée des chercheurs suggérait une réduction d’environ 21 % du temps d’exécution. Cependant, l’étude n’a pas examiné la qualité du code produit par l’IA, ni abordé les questions d’équité liées à la dépendance à cette technologie.

Il existe également des preuves que l’IA peut ralentir le temps de codage. Une étude randomisée menée par METR a impliqué 16 développeurs open‑source expérimentés qui ont travaillé sur 246 problèmes réels dans des dépôts qu’ils connaissaient bien. En utilisant les outils disponibles début 2025, dont Claude Sonnet 3.5 et 3.7 ainsi que Cursor Pro, ils ont mis environ 19 % plus de temps à accomplir leurs tâches, malgré les attentes selon lesquelles ces outils feraient gagner du temps.

Ensemble, ces études contredisent l’idée que l’IA permet aux développeurs de travailler plus rapidement. Au contraire, elles rendent le temps et la valeur des développeurs moins prévisibles pour les entreprises qui offrent des services web et pour les clients qui en bénéficient.

The Pricing Problem Nobody Talks About

Le modèle Temps & Matériel (T&M) est couramment utilisé dans le développement web pour l’achat de logiciels, car il répond à un problème récurrent du secteur : un projet évolutif.

Avec ce modèle, au lieu d’exiger que chaque fonctionnalité ou tâche soit définie avant le début du développement, les clients peuvent payer le temps d’ingénierie au fur et à mesure que le projet progresse et change.

Cependant, l’IA crée des accrocs dans ce modèle éprouvé. Lorsque la rémunération est directement liée aux heures d’ingénierie, un temps de développement plus efficace peut entraîner moins d’heures facturables pour les clients. Si l’IA permet d’obtenir les mêmes résultats en moins de temps, la technologie crée de la valeur pour les clients, mais la réduction des heures facturables signifie moins de revenus pour les prestataires.

La solution n’est pas d’encourager les développeurs à travailler plus lentement. Le modèle T&M fait désormais face à un problème structurel lié à la façon dont les prix et les incitations sont conçus. Utiliser des tarifs horaires pour déterminer la valeur peut être limitatif. Un acheteur peut connaître le coût exact de chaque heure d’ingénierie tout en restant incertain quant à l’investissement total nécessaire pour atteindre le résultat souhaité.

À mesure que l’IA modifie la productivité d’ingénierie, la question peut évoluer de:

“What does a developer hour cost?” → “What happens to the value when fewer developer hours are required?”

Les résultats de METR compliquent cette interrogation. Si les développeurs pensent pouvoir économiser du temps alors qu’en réalité ils en prennent davantage, ni l’adoption de l’IA ni la productivité perçue ne suffisent à démontrer une valeur financière. C’est pourquoi les organisations ont besoin d’une gouvernance capable de mesurer ce qui s’est réellement produit.

The Governance Gap Has Four Owners

Discuter de la gouvernance autour du développement assisté par l’IA doit aller au‑delà des politiques qui régissent quels outils les développeurs peuvent utiliser.

Il existe au moins quatre types de propriété que les organisations d’ingénierie doivent définir.

1. Who owns the code?

L’IA peut générer une implémentation, mais elle ne peut pas servir d’excuse à un développement sans responsabilité. Quelqu’un doit rester responsable de la révision, des tests et de l’approbation du code jusqu’à son déploiement en production.

2. Who owns the risk?

Un code plus rapide n’est précieux que s’il ne crée pas de problèmes ailleurs. Une étude empirique du code généré par l’IA a identifié des faiblesses de sécurité dans 29,5 % des extraits Python examinés et 24,2 % des extraits JavaScript. La recherche a également mis en évidence des vulnérabilités couvrant 43 catégories du Common Weakness Enumeration.

Cependant, l’étude a constaté que le fait d’alimenter les avertissements d’analyse statique dans Copilot Chat pouvait corriger jusqu’à 55,5 % des problèmes de sécurité identifiés. La recherche montre comment l’IA peut créer et résoudre des problèmes de codage, mais les organisations ont besoin de processus pour déterminer comment valider ses résultats.

NIST’s SP 800-218A reflète ce principe en étendant son Secure Software Development Framework avec des bonnes pratiques qui prennent en compte l’IA générative et les modèles de fondation à double usage.

3. Who owns the productivity gain?

Des accords commerciaux dès le départ sont essentiels pour déterminer qui doit bénéficier des gains d’efficacité. L’IA peut aider les clients à dépenser moins, permettre aux équipes de livrer davantage de logiciels, ou ne générer aucun avantage financier à la fin du projet.

Ce qui demeure constant, c’est la nécessité de processus transparents et de la livraison d’un travail de qualité, convenu à l’avance.

4. Who owns prioritization?

L’IA peut rendre la génération de fonctionnalités moins coûteuse et plus rapide, mais elle ne peut pas décider si ces fonctionnalités sont nécessaires.

En fait, l’augmentation de la capacité de développement peut rendre la priorisation encore plus importante. Lorsque les équipes peuvent construire et expérimenter plus rapidement, quelqu’un doit encore déterminer quels résultats justifient le budget disponible et quelles idées doivent être abandonnées.

AI Governance Is Becoming a Finance Issue

Ces questions rendent la gouvernance de l’IA de plus en plus pertinente. Imaginez deux partenaires de développement facturant des tarifs horaires similaires.

L’un a intégré l’IA dans un processus d’ingénierie solide et atteint le résultat requis beaucoup plus rapidement, tandis que l’autre met plus de temps. Comparer uniquement leurs tarifs horaires n’informe pas suffisamment l’acheteur sur les processus qu’ils exécuteront.

Les acheteurs devront évaluer:

• L’investissement total attendu
• La responsabilité en cas de dépassements
• Les contrôles de qualité autour du travail généré par l’IA
• Comment les gains d’efficacité sont partagés

Le modèle T&M peut rester utile pour les deux parties s’ils acceptent consciemment l’incertitude des services. Les arrangements à prix fixe peuvent également fonctionner lorsque les exigences et les livrables sont stables.

Mais l’IA rend également intéressant l’examen de structures alternatives. Une approche consiste à établir une limite financière maximale tout en gardant la portée flexible. Ainsi, les fonctionnalités peuvent être priorisées en fonction de leur valeur métier dans ce cadre.

Si l’ingénierie devient plus efficace, les gains peuvent se traduire par des capacités produit supplémentaires plutôt que par du temps facturable additionnel. Les incitations commerciales devraient encourager le même résultat que les incitations d’ingénierie, créant ainsi des logiciels plus utiles aussi efficacement que possible.

The Same AI Conversation

Les dirigeants techniques doivent comprendre comment les incitations commerciales influencent la livraison. Les équipes financières et d’approvisionnement ont besoin d’une visibilité suffisante sur l’ingénierie assistée par l’IA afin d’évaluer si l’efficacité revendiquée génère une valeur mesurable.

Cela signifie qu’une gouvernance mature de l’IA ne peut pas se limiter à des listes de modèles approuvés, des contrôles de sécurité, des politiques de données ou des exigences de revue de code. Elle doit aborder la responsabilité, le risque financier, la priorisation et la propriété des gains de productivité.

Mais il existe une seconde question de propriété qui pourrait avoir un impact beaucoup plus important sur les budgets technologiques: qui possède la valeur créée ou perdue lorsque l’IA modifie la rapidité de construction des logiciels ?

Les organisations qui déterminent si une ingénierie plus rapide produit réellement de meilleurs produits, contrôlent les investissements et atteignent des résultats commerciaux mesurables seront celles qui pourront devancer leurs concurrents.

Si votre équipe de développement adoptait l’IA demain, votre modèle actuel de gouvernance et commercial vous dirait‑il même si cela a rendu la livraison plus précieuse ?