Tu as choisi ton outil de code assisté par IA — ou tu as décidé de t'en passer. Copilot, Cursor, Claude Code, ou juste ton cerveau et un terminal. Dans tous les cas, ça ressemblait à choisir ton éditeur de texte ou ta commande au café du coin : personnel, invisible, ça ne regarde personne.

Mais le truc avec les choix personnels — ils restent personnels uniquement jusqu'à ce que quelqu'un construise un tableau de bord. Et personne dans la hiérarchie n'avait de dashboard montrant à quel point tu utilises l'IA, à quelle fréquence tu acceptes ses suggestions, ou comment ton adoption se compare à celle du développeur assis deux bureaux plus loin. Jusqu'à cette semaine.

Le 10 avril, GitHub a livré des compteurs agrégés d'utilisateurs actifs du cloud agent via son API de métriques Copilot — une interface programmatique qui permet aux organisations de récupérer les données d'utilisation sans demander quoi que ce soit à qui que ce soit. Trois nouveaux champs : utilisateurs actifs quotidiens, hebdomadaires et mensuels pour l'agent cloud de Copilot. C'est le mode autonome où tu assignes une tâche de code à @copilot et il bosse dans le cloud, soumettant une pull request quand c'est terminé.

Mais le 10 avril n'était pas un événement isolé. C'était la troisième extension de métriques en huit jours — le point d'orgue d'un sprint qui a commencé fin mars quand GitHub a discrètement ajouté un champ used_copilot_coding_agent permettant aux admins de voir quels développeurs précis avaient déclenché des sessions d'agent. C'était le travail préparatoire. Voici l'escalade :

  • 2 avril — Activité CLI par utilisateur. Nombre de sessions, nombre de requêtes, consommation de tokens, version du CLI — tout ça par développeur. Ils ont compté tes frappes clavier.
  • 6 avril — Suivi actif vs. passif de la code review. Tu as choisi la review Copilot, ou c'est une policy du repo qui l'a assignée automatiquement ? Les propres mots de GitHub : "Mesurer l'engagement réel, pas juste la couverture." Ils ont mesuré ton enthousiasme.
  • 10 avril — DAU/WAU/MAU pour les agents cloud. Les métriques d'engagement classiques dont chaque product manager dépend pour vivre ou mourir, désormais appliquées aux développeurs utilisant l'IA. Ils ont mis ça en graphique.

Trois mises à jour. Huit jours. Chacune ajoute un nouveau point de données par développeur aux endpoints API de l'organisation — ce qui signifie que n'importe quelle entreprise avec une licence GitHub Enterprise peut interroger ces chiffres de manière programmatique et les injecter dans n'importe quel outil d'analytics RH ou tableau de bord de performance qu'elle utilise déjà.

GitHub n'est pas le seul à construire cette couche d'observation. L'offre entreprise de Cursor expose des ventilations d'utilisation IA par développeur. Claude Code d'Anthropic rend visible les données de coût par session aux admins d'organisation. OpenAI Codex a lancé avec des analytics d'utilisation intégrées à son offre entreprise quand les licences Codex-only sont arrivées le 3 avril. Les implémentations diffèrent, mais le schéma converge : chaque outil de code IA majeur génère désormais une trace écrite de combien chaque personne l'utilise exactement.

Et c'est là que le tableau de bord rencontre la réalité.

J'ai couvert l'étude "Debt Behind the AI Boom" hier — 304 000+ commits vérifiés générés par IA à travers 6 275 repos. Le titre qui dérange : les équipes où le code généré par IA dépassait 40 % de la production totale ont connu des taux de rework 20 à 25 % plus élevés. La métrique qui te fait passer pour productif sur un dashboard — forte adoption de l'IA, beaucoup de tâches déléguées à l'agent, beaucoup de suggestions acceptées — corrèle avec de pires résultats concrets. Si tu as raté cet article, la version courte : l'IA écrit des bugs vite aussi.

C'est la loi de Goodhart dans toute sa splendeur : quand une mesure devient un objectif, elle cesse d'être une bonne mesure. Sauf que maintenant, l'objectif porte ton nom.

Le dilemme est brutal. Les développeurs qui s'appuient lourdement sur les agents IA apparaissent comme des "early adopters exemplaires" dans les nouvelles métriques — exactement le signal qu'un manager non technique va optimiser. Les développeurs qui utilisent l'IA de manière sélective, rejetant les mauvaises suggestions et écrivant le code critique à la main, ressemblent à des retardataires sur un tableur qu'ils n'ont jamais vu. Et refuser complètement ? Ce n'est plus une préférence personnelle — c'est un trou visible dans un jeu de données que les appels API de ton organisation alimentent chaque nuit.

Soyons clairs : GitHub n'a jamais dit que ces métriques étaient destinées aux évaluations de performance. Leur annonce de GA du 27 février présentait la chose comme un moyen d'aider les organisations à "suivre les tendances, prendre des décisions éclairées sur le déploiement, et construire des rapports." Mais le même article de blog esquissait une feuille de route allant "du suivi de l'adoption à la mesure de l'impact." Quand les données sont derrière un endpoint API, les cas d'usage suivent — que l'éditeur les ait prévus ou non.

Ce qui a commencé comme "voici un petit autocomplete bien pratique" a maintenant un chiffre attaché à ton nom. Et si tu penses que ça va rester cantonné au code, détrompe-toi. Les designers utilisant des outils de maquettage IA, les PM utilisant des générateurs de specs IA, les marketeurs utilisant de la rédaction IA — chaque plateforme servant les travailleurs du savoir construit la même couche de mesure. L'infrastructure est déjà en production ; elle attend juste le dashboard.

L'ère du volontariat dans l'adoption des outils IA ne s'est pas terminée par un décret d'entreprise, mais par une API de métriques. Trois mises à jour en huit jours. La métrique est le mandat désormais. Choisis en conséquence.