Qu'est-ce qu'on interdit ? La politique d'équipe, et les chiffres qui prouvent qu'elle a marché
La plupart des équipes ont la réunion « faut-il utiliser l'IA ». Peu écrivent la politique. Une page, cinq chiffres, et la question qui tranche.
La plupart des équipes ont la réunion « faut-il utiliser l'IA ». Peu ont la réunion « quelle est la politique IA de notre équipe, écrite noir sur blanc ». C'est la seconde qui rapporte, parce que c'est le seul endroit où les règles des ingénieurs et les attentes du business figurent dans le même document.
La liste est plus courte que vous ne le pensez
Ce que l'agent peut toucher, et ce qui est interdit. Le code sauf si la tâche dit migrate, le code généré, tout ce qui touche à la conformité. Une ligne par exclusion.
Ce que contient chaque assistée par l'IA. La tâche qu'elle a exécutée, la taille du , les commandes qui sont passées. Si la PR ne peut pas dire de quel fichier de tâche elle vient, c'est qu'elle n'en vient pas.
Ce qui n'entre jamais dans un . Les données clients, les identifiants, tout ce qui est sous NDA.
Quel outil est le standard. Pour que les règles, les et les fichiers d'instructions soient partagés au lieu d'être propres à chaque développeur. Les règles sont dans AGENTS.md ; ce qui est propre à l'outil standard va dans son fichier, qui reste court. L'outil de tous les autres lit les mêmes règles.
Où sont écrites les exceptions. Chaque règle ci-dessus en aura une : un @Input() classique conservé sur un composant mis à niveau, un script ponctuel exempté de la limite de taille, un échantillon de données synthétiques autorisé dans un prompt parce que rien dedans n'est réel. Chacune reçoit un court , daté, avec la raison, et AGENTS.md pointe vers le dossier, donc l'agent les lit aussi.
L'exception, ça va. L'exception non documentée, c'est la règle qui meurt en silence.
C'est ça, la politique. Une page. Il faut un après-midi à une équipe pour l'écrire, et c'est cet après-midi qui décide si l'année prochaine sera celle d'une équipe plus rapide ou celle d'un projet mort.
Les chiffres, sinon ça reste une impression
Le business a un chiffre aujourd'hui : la démo a pris un après-midi. L'équipe n'en a aucun, et une impression de vitesse n'est pas un chiffre : dans un essai mené début 2025, des développeurs expérimentés s'attendaient à ce que l'IA les rende 24 % plus rapides, et elle les a rendus 19 % plus lents. La seconde moitié de la politique, ce sont donc cinq chiffres, par module, suivis pour la méthode rapide et pour la méthode de l'équipe, côte à côte :
| Métrique | Comment l'obtenir | Pourquoi le business s'y intéresse |
|---|---|---|
| Temps de cycle par changement | du ouvert au merge, en jours ouvrés (pas le lead time de , du au déploiement) | remplace l'après-midi de la démo par un vrai chiffre |
| Retravail en revue | lignes changées en revue divisées par les lignes de la première PR | quelle part du « rapide » a été refaite |
| Charge de revue | commentaires et heures de revue par PR | le coût caché du gros diff |
| Défauts échappés | bugs dans le module dans les 30 jours après la mise en production | met fin à l'argument « ça marche à l'écran » |
| Taille des PR | fichiers et lignes par PR | le levier que l'équipe contrôle directement |
D'autres équipes ont déjà vu ce que donne la méthode rapide. Sur 10 000 développeurs, une forte adoption de l'IA est allée de pair avec 98 % de pull requests fusionnées en plus, des pull requests 154 % plus grosses et des revues 91 % plus longues. Les petits changements reçoivent plus vite leurs premiers commentaires de revue, et DORA a constaté que travailler par petits lots amplifie l'effet positif de l'IA sur le produit.
Règles : mesurez aussi la méthode rapide, honnêtement, pour que ce soit une comparaison et pas une accusation. Un rapport mensuel, une page, sans noms. Proposez-le comme une aide, « voici comment on montre les progrès au conseil », pas comme une défense.
Notre hypothèse : la méthode de l'équipe est plus lente sur le premier module et plus rapide au troisième, avec des revues plus légères et moins de défauts échappés. DORA s'attend à un creux similaire au début, quand les équipes adoptent l'IA, mais personne n'a mesuré notre cas. C'est pour ça qu'on compte. Si ça n'apparaît pas, la méthode de l'équipe doit changer aussi, et les chiffres diront où.
Lis AGENTS.md, package.json (ses scripts), la configuration lint et celle des frontières, docs/tasks/TEMPLATE.md et, si le repo en a, les descriptions des dix dernières pull requests (gh pr list). Rédige notre politique IA en une page sous ces titres : ce que l'agent peut toucher ; ce que contient chaque PR assistée par l'IA ; ce qui n'entre jamais dans un prompt ; l'outil standard et où se trouvent ses ajouts ; où sont consignées les exceptions. Là où le repo énonce déjà une règle, cite le fichier et indique si un outil l'impose ou si seul un texte l'énonce. Là où une règle n'existe que dans la tête des gens, écris « UNWRITTEN » et propose la ligne. N'invente pas de règles que le repo ne laisse pas deviner.
La liste « UNWRITTEN » est le vrai résultat. C'est l'écart entre la politique que l'équipe croit avoir et celle que l'agent peut lire.
La question qui tranche
Quand la démo sera présentée à la direction, et elle le sera, une question suffit à trancher l'essentiel de la réunion :
Vous voulez que ça marche seulement cette année, ou vous le voulez encore sûr et maintenu dans cinq ans ?
Tout, dans ce parcours, découle de la réponse. Si la réponse est cinq ans, la politique ci-dessus est le plan, les chiffres sont la preuve, et la vitesse de l'agent se justifie. Si la réponse est cette année, rien dans cette série ne vous aidera, et c'est aussi une réponse honnête.
Lundi
- Écrivez la politique d'une page. Un après-midi, toute l'équipe, les cinq titres ci-dessus.
- Lancez les cinq chiffres sur le prochain module, les deux méthodes, honnêtement.
- Mettez la politique dans le repo à côté de
AGENTS.md, pour que l'agent la lise aussi.
Exercice : lancez le prompt ci-dessus sur le repo de démo. AGENTS.md, la configuration et docs/tasks/TEMPLATE.md couvrent déjà la plupart des titres.
Sources
- , Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, juillet 2025
- DORA, DORA's software delivery performance metrics
- Faros AI, The AI Productivity Paradox Report 2025, juillet 2025
- Sadowski et al., Google, Modern Code Review: A Case Study at Google, ICSE-SEIP 2018
- DORA, Introducing DORA's inaugural AI Capabilities Model, septembre 2025
- DORA, How to measure the business value of generative AI, juin 2026
La dernière partie de la série gratuite qui accompagne le Vite et sûr : l'IA dans votre code Angular. En salle, votre équipe écrit la version longue de cette page avant de partir.
Vite et sûr : l'IA dans votre code Angular
Laissez des agents écrire de l'Angular sous règles, modernisez le code legacy sans casser la production, et gardez le tout sécurisé, en trois jours, sur un code à l'échelle d'une entreprise.
Voir le programme