Situation réelle

Un développeur utilise ChatGPT pour débugger un problème. Il colle un extrait de code contenant un secret d’API dans le prompt. Un autre utilise un outil IA pour générer de la documentation — l’outil stocke les données sur des serveurs externes. Un troisième installe une extension VS Code qui analyse le code en temps réel via un service cloud. Personne n’a fait de mal intentionnellement. Mais personne n’avait de cadre pour savoir ce qui était autorisé.

Ce que j’ai observé : dans la majorité des entreprises, l’usage de l’IA par les développeurs précède la gouvernance. Les outils sont déjà utilisés avant que quiconque ne se pose la question de la politique d’usage.

Le faux problème

La question habituelle : « Faut-il interdire l’utilisation de l’IA ? »

En réalité, interdire ne fonctionne pas. Les développeurs utiliseront l’IA quoi qu’il arrive — sur leur machine personnelle, via un navigateur, en dehors du réseau d’entreprise. L’interdiction ne supprime pas l’usage, elle le rend invisible.

L’autre piège : tout autoriser sans cadre. L’innovation sans limites, c’est le shadow IT version IA — avec des risques de fuite de données, de non-conformité et de dépendance non maîtrisée.

Le vrai enjeu CTO

Le vrai enjeu est de construire un cadre qui protège sans paralyser. Un cadre qui dit clairement : voici ce qui est autorisé, voici ce qui ne l’est pas, voici pourquoi.

Les trois axes de la gouvernance IA

1. La confidentialité des données. Quelles données peuvent être envoyées à un service IA externe ? Le code propriétaire ? Les données clients ? Les secrets d’infrastructure ? La réponse doit être explicite, écrite, accessible à tous.

2. La qualité et la responsabilité. Qui est responsable du code généré par l’IA ? Le développeur qui l’a commité. Toujours. L’IA ne porte pas la responsabilité — c’est un outil, pas un auteur. Cette règle doit être claire.

3. La conformité réglementaire. RGPD, AI Act européen, régulations sectorielles — les usages de l’IA peuvent avoir des implications légales. Le CTO doit s’assurer que les pratiques de l’équipe sont compatibles avec le cadre réglementaire applicable.

Cadre de décision

  1. Établir une politique d’usage en trois zones. Zone verte : usages autorisés sans restriction (autocomplétion locale, documentation, tests sur du code non sensible). Zone orange : usages autorisés sous conditions (code propriétaire, avec outil approuvé et données anonymisées). Zone rouge : usages interdits (données clients, secrets, code soumis à des contraintes réglementaires).

  2. Approuver les outils, pas les usages. Plutôt que de réglementer chaque cas d’usage, établir une liste d’outils approuvés avec leurs conditions d’utilisation. Plus simple à maintenir, plus simple à communiquer.

  3. Former plutôt que contrôler. Un développeur informé des risques fera de meilleurs choix qu’un développeur surveillé. La formation prend une heure. La surveillance est permanente et inefficace.

  4. Réviser trimestriellement. Le paysage des outils IA change tous les trois mois. La politique doit suivre. Une politique de janvier 2025 est obsolète en juin 2025.

  5. Impliquer les développeurs dans la rédaction de la politique. Une politique imposée sans consultation sera contournée. Une politique co-construite sera respectée.

Retour terrain

Entreprise A — Aucune politique. Les développeurs utilisent librement ChatGPT, Copilot, des extensions diverses. Un audit révèle que du code propriétaire a été envoyé à trois services différents sans chiffrement. Coût de remédiation : deux semaines d’audit et une notification RGPD.

Entreprise B — Politique stricte : seuls les outils hébergés on-premise sont autorisés. Résultat : les développeurs utilisent les outils interdits sur leur machine personnelle. L’entreprise n’a aucune visibilité sur les usages réels.

Entreprise C — Politique en trois zones, co-rédigée avec les tech leads. Outils approuvés avec conditions claires. Formation obligatoire d’une heure pour tout nouveau développeur. Résultat : usages cadrés, adoption élevée, aucun incident en huit mois.

Erreurs fréquentes

  • Rédiger une politique de 30 pages. Personne ne la lira. Une page suffit. Les détails vont dans un wiki accessible.
  • Ignorer le sujet en espérant qu’il se régule seul. Il ne se régule pas. Il s’installe en shadow IT.
  • Confier la gouvernance IA au juridique seul. Le juridique ne comprend pas les usages techniques. Le CTO ne comprend pas toujours les implications légales. La gouvernance IA est un sujet transverse.
  • Mettre à jour la politique une fois par an. En IA, un an est une éternité. Trimestriel minimum.

Si c’était à refaire

  • Je rédigerais la politique avant que les outils ne soient déployés. Pas après. Le cadre doit précéder l’usage.
  • Je commencerais par les risques, pas par les règles. Expliquer pourquoi avant de dire quoi. Les développeurs comprennent mieux une règle quand ils comprennent le risque qu’elle adresse.
  • Je créerais un canal dédié (Slack, Teams) pour les questions sur l’usage de l’IA. Les zones grises sont inévitables — mieux vaut qu’elles soient posées ouvertement que contournées en silence.

Pour approfondir