Rédiger la politique IA d’une équipe de développement

Une politique IA qui fonctionne pour une équipe de développement tient sur une page, autorise plus qu’elle n’interdit, et tranche quatre questions : quelles données vers quels outils, ce qui exige une revue humaine, qui répond du code généré, et où sont les limites. Le reste peut attendre la version deux.

Nous en avons lu beaucoup, en audit comme en accompagnement. Les politiques qui échouent se ressemblent : dix pages écrites par le juridique, des interdictions générales, aucun outil recommandé. Celles qui marchent aussi : courtes, concrètes, versionnées dans le repo, avec un responsable nommé.

L’interdiction fabrique du shadow AI

Commençons par l’échec le plus courant. Une organisation qui interdit les outils IA, ou les tolère sans en fournir, n’empêche pas leur usage : elle le rend invisible. Les développeurs passent par leurs comptes personnels, sur des outils grand public sans clause de confidentialité, et votre code part là où vous ne vouliez pas qu’il aille, sans trace, sans contrat, sans recours.

L’organisation perd deux fois. Le risque demeure, et l’apprentissage ne s’accumule pas : personne ne partage un workflow qu’il n’a pas le droit d’avoir, donc chacun réinvente en cachette, et mal. Au bout du compte, l’usage continue et le CTO ne le voit plus, ce qui est la pire position possible.

La conséquence pratique : une politique crédible commence par fournir les outils, avec des comptes d’entreprise et un budget assumé. On ne peut exiger le respect d’un cadre que s’il offre une voie autorisée praticable.

Les quatre décisions qui font une politique IA

Côté données, nommez les outils approuvés et le type de compte requis : un compte entreprise, avec des clauses de non-entraînement sur vos données et une rétention limitée. Dites ce qui ne va jamais dans un prompt : secrets, données clients nominatives, code couvert par un NDA spécifique. C’est la décision qui protège le plus, et la plus simple à énoncer.

Pour la revue humaine, évitez "tout", qui devient "rien" sous le volume. Dressez plutôt une carte des chemins sensibles (authentification, paiements, données personnelles, migrations) où un relecteur expérimenté est requis quel que soit l’auteur du code. La sécurité du code généré justifie à elle seule cette carte.

Sur la responsabilité, la règle qui a fait ses preuves tient en une phrase : la personne qui merge répond du code, qu’il ait été écrit à la main ou généré. Aucune catégorie "c’est l’agent" ne doit diluer cette responsabilité. L’attribution complète la règle : signaler ce qui a été généré, quand c’est utile, aide le relecteur à doser son attention, et personne ne devrait le vivre comme un aveu.

Restent les limites : les repos exclus, les usages exclus, la question des licences sur le code généré, et la personne à contacter en cas de doute. Une limite n’est utile que si elle est courte et motivée. Une interdiction dont personne ne comprend la raison finit contournée.

Une page dans le repo plutôt qu’un PDF sur l’intranet

La forme compte autant que le fond. Une page en markdown, dans le repo : une politique qui vit à côté du code se lit, se corrige par pull request et reste à jour, alors qu’un PDF sur l’intranet meurt le jour de sa publication. Les exemples concrets valent mieux que les principes : "voici une tâche bien déléguée", "voici ce qu’on ne met pas dans un prompt".

Faites-la appliquer par la machine chaque fois que c’est possible. Ce qui peut être vérifié en CI (exigences de tests, scan de secrets, analyse statique) doit l’être par la CI. Une règle outillée n’a pas besoin d’être rappelée. Celles qui reposent sur la seule bonne volonté doivent rester rares, courtes et comprises.

Ce qui la fait vivre

Une politique écrite en 2024 et jamais revue interdit probablement des usages devenus standard et ignore des risques apparus depuis. Prévoyez une révision par trimestre, portée par les personnes qui pilotent le déploiement des agents dans l’équipe : la politique se nourrit de ce qu’elles observent et se révise avec le terrain.

Le signal de réussite est simple : les développeurs citent la politique au moment de prendre une décision, au lieu de la découvrir lors d’un incident. On n’obtient cela qu’avec un document court, utile, qui autorise davantage qu’il n’interdit.

Si vous partez de zéro, écrivez la version une en une réunion : les quatre décisions ci-dessus, une page, un responsable. Poser ce cadre fait souvent partie de la première journée de nos missions d’ingénierie agentique, avant même le choix des outils.