Les équipes vous montrent tout le temps des chiffres d'usage de l'IA. Ce qui est plus difficile à trouver, c'est quelque chose qu'elles construisent différemment à cause de cela.
Chaque organisation d'ingénierie à laquelle j'ai parlé cette année a une version du même graphique. Les activations de sièges qui grimpent. Les dépenses en tokens qui grimpent. Une diapositive quelque part annonce 80 % d'utilisateurs actifs hebdomadaires. Puis on s'assoit dans la réunion de planification de cette équipe, et rien dans leur façon de construire du logiciel n'a changé.
Cet écart est le vrai problème, et la façon dont nous mesurons généralement l'adoption de l'IA est, par accident, conçue pour le masquer.
Tout ce que vous mesurez est une métrique d'usage
Les dépenses en tokens vous disent que quelqu'un a tapé dans une case. Le nombre de pull requests vous dit que des commits sont arrivés. « Pourcentage de code écrit par IA » vous dit qu'une suggestion d'autocomplétion a été acceptée. Rien de tout cela ne vous dit que le travail s'est amélioré.
La loi de Goodhart, à l'heure exacte. Dès qu'un chiffre devient l'objectif, il ne décrit plus la réalité, mais l'incitation.
La version la plus claire de cet échec n'est même pas spécifique à l'IA. Tout ingénieur a déjà vu une équipe franchir un seuil de couverture avec des tests qui n'affirment rien. expect(true).toBe(true). Ligne couverte, chiffre au vert, rien de testé. La métrique était satisfaite et l'objectif abandonné, et le tableau de bord n'a aucun moyen de faire la différence.
Les métriques d'usage de l'IA ont la même forme. Si je dis à mon équipe que l'usage est un signal de performance, l'usage grimpe en une semaine, et je n'ai rien appris, sauf qu'ils savent lire les incitations. Ce que je savais déjà.
Meilleure question : si vous supprimiez ces outils demain, qu'est-ce qui casserait ? Pas ce dont les gens se plaindraient. Ce qui casserait vraiment. Si la réponse honnête est « rien, les gens seraient un peu agacés », vous n'avez pas de l'adoption. Vous avez un abonnement.
Trois choses sont appelées adoption. Une seule dure.
Quand je creuse ce que signifie « nous avons adopté l'IA » dans une équipe donnée, c'est toujours une de trois choses, et elles n'ont rien de comparable en valeur.
Quelqu'un modifie sa propre boucle de travail. Il l'utilise pour écrire ses messages de commit, ou pour s'orienter dans du code inconnu. Réel, utile, presque totalement non durable. Au premier deadline serré, cette personne retombe sur la méthode dont elle sait déjà qu'elle fonctionne. Ce n'est pas un problème de discipline. Sous pression, les gens prennent le chemin comportant le moins d'incertitude disponible, et un nouveau workflow est par définition celui à forte incertitude.
Quelqu'un délègue durablement une tâche récurrente. Pas « j'ai utilisé l'IA aujourd'hui », mais « je ne fais plus ça, un workflow s'en charge, et je vérifie le résultat ». Cela survit aux deadlines, parce que revenir en arrière créerait du travail supplémentaire pour cette personne. Mais cela s'en va aussi quand elle s'en va.
Ou bien l'équipe change délibérément la façon de faire quelque chose. Quelqu'un a décidé qu'une étape du processus fonctionne désormais d'une certaine manière, l'a écrit, et cela tient, que telle ou telle personne soit enthousiaste ou non. Seule la troisième option survit au turnover et à un mauvais trimestre.
La plupart des organisations célèbrent la première, atteignent parfois la deuxième, et n'arrivent jamais à la troisième. Parce que la troisième n'est pas un problème d'outillage. Acheter des licences relève d'une conversation budgétaire. Changer une norme signifie dire tout haut que l'ancienne façon était moins bonne, puis en assumer la responsabilité quand la nouvelle casse quelque chose en semaine trois.
Chez Webflow, ce qui a tenu chez nous, c'est de traiter les prompts comme des artefacts partagés et versionnés plutôt que comme une propriété personnelle. Auparavant, les gens les gardaient dans des fichiers de brouillon, les ajustaient en privé pendant des semaines, et les perdaient au prochain changement de machine. Aujourd'hui, les bons prompts vivent dans le dépôt, avec un propriétaire, une note sur quand les utiliser, et une revue à chaque modification, comme n'importe quel autre code. Cela n'a rien coûté en outillage. Ce qu'il a fallu, c'est décider que cette catégorie de chose valait la peine d'être maintenue.
Cela tient parce que ça ne repose sur l'enthousiasme de personne. Les nouveaux ingénieurs héritent de la bonne version, au lieu de passer un mois à la redécouvrir. Quand quelqu'un trouve une amélioration, tout le monde en profite, au lieu qu'une seule personne devienne discrètement meilleure dans son travail.
Les agents démarrent bien, mais le gèrent mal
Voici le schéma qui tue l'adoption avant même qu'une équipe n'atteigne ce troisième niveau.
Le levier se concentre au début d'une tâche. Passer d'une page blanche à un brouillon plausible est nettement plus rapide qu'avant. Passer d'un brouillon plausible à quelque chose de correct et livrable n'est pas plus rapide du tout, et cette moitié-là vous appartient toujours.
Un ingénieur se rend alors compte qu'il peut lancer cinq choses à la fois, les envoie toutes, et se sent productif en le faisant. Puis cinq choses reviennent nécessitant une revue, et cette revue se déroule de façon strictement séquentielle dans une seule tête, sur un travail qu'on n'a pas écrit et qu'il faut reconstruire de zéro. On n'a pas parallélisé. On a sérialisé sur sa propre attention, avec une profondeur de file d'attente que personne n'aurait choisie délibérément.
Ces personnes finissent la semaine plus occupées et moins sûres d'elles que la semaine précédente, ce qui est une expérience réellement pire. Beaucoup de gens essaient les workflows agentiques une fois, ressentent exactement cela, et arrêtent discrètement. Des semaines plus tard, cela apparaît comme une baisse d'usage et se voit diagnostiqué comme une lacune de formation.
Ce n'en est pas une. C'est un problème de forme du travail. Déléguer à un agent a le même plafond que déléguer à une personne : la capacité de revue de celui ou celle qui reste responsable en dernier ressort. Les équipes qui en tirent une vraie valeur ont précisément déterminé quel travail peut être délégué en toute sécurité avec une simple vérification, et lequel ne le peut pas, plutôt que de traiter tout comme également délégable.
On ne peut pas piloter une adoption qu'on ne peut pas évaluer
Si vous ne pouvez pas évaluer le résultat, tout débat sur l'efficacité d'un workflow devient un débat de ressenti. Et les débats de ressenti sont gagnés par la personne la plus confiante dans la salle, ce qui est une manière terrible de gérer l'ingénierie.
Évaluer ne veut pas dire des benchmarks. Les benchmarks vous disent qu'un modèle est bon de façon générale. Vous devez savoir si ce workflow est bon dans la chose spécifique que fait votre équipe, ce qu'aucun benchmark ne couvre. Quelques dizaines de cas réels tirés de votre propre domaine, notés selon une grille que vous avez écrite, relancés chaque fois que quelqu'un modifie un prompt ou change de modèle. Petit, c'est très bien. Le but n'est pas la précision, c'est d'avoir un chiffre qui bouge pour des raisons que vous comprenez.
Sans cela, vous ne pouvez pas distinguer un workflow qui s'est amélioré d'un autre dont les échecs sont juste devenus plus fluides. Dans une démo, les deux se ressemblent à s'y méprendre.
Ce que je ferais concrètement
Éliminez définitivement une tâche manuelle récurrente par personne. Pas « essayer l'IA dessus ». Retirez-la de sa semaine et faites du workflow le responsable officiel. Une tâche qui reste morte vaut mieux que dix expériences.
Officialisez exactement une norme d'équipe, par écrit, ce trimestre. Une seule. Assez petite pour que vous l'appliquiez vraiment, assez précise pour que quelqu'un puisse la briser.
Arrêtez de rapporter l'usage vers le haut. Rapportez le résultat que cet usage était censé produire, y compris les trimestres où ce chiffre paraît moins bon que ne l'aurait fait l'usage.
Rien de tout cela ne nécessite un nouvel outil, et c'est bien là l'essentiel. Les outils sont la partie la moins chère de tout ça, et pourtant celle qui capte le plus d'attention. La partie coûteuse, c'est d'accepter de changer délibérément, publiquement, la façon dont une équipe travaille, avec son nom associé à la décision.
