Gérer l'IA, c'est gérer
Depuis quelques mois, je construis des choses avec Claude Code. Pas juste superviser des ingénieurs qui construisent des choses, mais construire moi-même : écrire des spécifications, évaluer les résultats, itérer quand le résultat ne correspondait pas à ce que je voulais dire.
Quelque part autour du deuxième mois, j'ai réalisé que je n'apprenais pas à coder. J'apprenais à gérer.
Le problème de la spécification
Quand on travaille avec un agent IA, on écrit une spécification. L'agent produit le travail. On évalue le résultat. Si c'est mauvais, on ne corrige pas le code. On corrige la spécification.
Cette boucle devrait sembler familière à quiconque a déjà géré des gens.
Quand votre équipe livre quelque chose que vous ne vouliez pas, l'instinct est de penser qu'ils se sont trompés. Mais la plupart du temps, le brief était ambigu. Vous saviez ce que vous vouliez dire. Eux, non.
L'IA rend ça brutalement clair. Contrairement à un humain, un agent IA ne demandera pas « tu voulais dire X ou Y ? » Il construit simplement ce que vous avez décrit. Chaque ambiguïté est silencieusement résolue par des suppositions machine plutôt que par l'intuition humaine. On ne découvre que sa spécification était floue qu'en voyant le résultat.
La spécification comme discipline s'avère être la même discipline qui sépare les bons gestionnaires des mauvais.
Le simulateur de vol
Quand on gère des humains, on a une poignée de boucles de rétroaction par semaine. Des directives le lundi, des résultats le vendredi, du feedback, de l'attente. Peut-être vingt cycles par personne par année.
Avec l'IA, j'ai des dizaines de boucles par jour. Spécifier, voir le résultat, réaliser que la spec était ambiguë, réécrire, voir l'amélioration. En un après-midi, je passe par plus d'itérations sur la communication claire de mon intention que la plupart des gestionnaires en un mois.
C'est de la gestion en simulateur de vol. La même compétence fondamentale, des ordres de grandeur de plus en répétitions.
Les compétences qui se transfèrent
Les parallèles sont structurels, pas superficiels :
Lâcher prise. La partie la plus difficile de la gestion, c'est de faire confiance à quelqu'un d'autre pour faire un travail qu'on pourrait faire soi-même. Chaque ingénieur qui résiste à l'IA parce que « je pourrais l'écrire mieux moi-même » est le même que le gestionnaire incapable d'arrêter de microgérer. L'IA vous force à confronter ça plus vite.
Évaluer le résultat, pas le processus. Les bons gestionnaires ne regardent pas leur équipe taper. Ils évaluent le résultat par rapport à l'intention. Avec l'IA, on ne peut littéralement pas observer le processus. On spécifie et on juge.
Assumer le brief. Quand l'IA produit quelque chose de mauvais, le problème est presque toujours ma spécification. J'ai appris à me demander « qu'est-ce que j'ai oublié de spécifier ? » avant « qu'est-ce que l'agent a mal fait ? » Les grands gestionnaires développent ce réflexe au fil des années. L'IA le développe en quelques semaines.
Anticiper l'ambiguïté. Après des milliers de tours de « ma spec était floue et l'IA a mal comblé le vide », on développe un instinct pour repérer l'ambiguïté avant d'appuyer sur envoyer. On commence à relire ce qu'on écrit du point de vue du récepteur. C'est la compétence de gestion la plus difficile, et l'IA donne plus de pratique à cet exercice que n'importe quel cours de gestion ne pourrait jamais le faire.
Le côté émotionnel
La première fois qu'un agent IA réécrit quelque chose sur lequel vous avez passé des heures à concevoir, vous le ressentez. De la défensivité, une perte de propriété, un murmure d'inutilité. « Si la machine peut faire ça, à quoi est-ce que je sers ? »
Les nouveaux gestionnaires ressentent exactement la même chose. Regarder quelqu'un résoudre un problème différemment de comment on l'aurait fait. L'impulsion d'intervenir. Apprendre à vivre avec cet inconfort est le noyau émotionnel de la délégation.
L'IA compresse ce parcours. En gestion traditionnelle, on confronte ces sentiments graduellement au fil des mois. Avec l'IA, on les rencontre dès la première semaine. J'ai vu des ingénieurs traverser ce qui ressemble aux cinq étapes du deuil, de « ça ne peut rien produire de bon » à « mon travail est de spécifier, pas d'implémenter ».
Les ingénieurs qui s'adaptent le plus vite ne sont pas les plus compétents techniquement. Ce sont ceux qui peuvent séparer leur identité de leur production. Ce n'est pas un trait technique. C'est le même trait qui fait de quelqu'un un bon gestionnaire.
L'IA n'entraîne pas l'empathie ou la capacité de motiver quelqu'un à travers une mauvaise semaine. Mais la résilience de déléguer, d'accepter une production imparfaite, d'assumer le brief plutôt que de contrôler l'exécution ? Ça, elle l'entraîne à grande vitesse.
Ce qu'est ce site web
Ce site au complet est un ensemble de spécifications. Pas des spécifications de code. Des spécifications de transformation. Des documents assez précis pour qu'une équipe d'humains puisse les lire et savoir quoi construire, comment travailler, et à quoi ressemble le succès.
Je les ai écrits de la même façon que j'écris des spécifications pour Claude Code : en itérant jusqu'à ce que le résultat corresponde à mon intention. La différence, c'est qu'ici, les « agents » sont des humains qui entreprennent une transformation organisationnelle, et la boucle de rétroaction se mesure en mois, pas en minutes.
Construire avec l'IA ne m'a pas appris à coder. Ça m'a appris à spécifier. Et il s'avère que c'est la chose la plus importante qu'un PDG fait.
L'implication inconfortable
Si gérer l'IA développe des compétences de gestion à un rythme accéléré, alors l'échelle de carrière traditionnelle (des années comme contributeur individuel, puis chef d'équipe, puis gestionnaire) n'est plus le seul chemin vers la maturité de gestion.
Un ingénieur junior qui passe un an à travailler avec des agents IA peut développer des instincts de spécification et de délégation plus forts qu'un gestionnaire avec trois ans d'expérience, simplement à cause du nombre de répétitions.
Ça ne veut pas dire que la gestion de l'IA remplace la gestion humaine. Mais le noyau cognitif (communication claire, délégation, évaluation) et la résilience émotionnelle que ça exige (lâcher prise, accepter l'imperfection, assumer le brief) sont entraînables à la vitesse de l'IA.
La voie de contributeur individuel et la voie de gestion commencent à se confondre. C'est probablement une bonne chose.
Le recadrage
Les ingénieurs sont mal à l'aise avec l'IA parce qu'elle est non fiable. Même entrée, résultat différent. Ça semble cassé pour quelqu'un formé aux systèmes déterministes.
Mais les gestionnaires ont toujours opéré de cette façon. On donne le même brief à deux personnes et on obtient des résultats différents. On apprend à écrire de meilleurs briefs, à établir des attentes plus claires, à évaluer plus soigneusement, et à vivre avec l'inconfort de ne pas être en contrôle.
Les ingénieurs qui travaillent avec l'IA n'apprennent pas à tolérer la non-fiabilité. Ils apprennent à gérer. Ils ne le savent juste pas encore.
François Lane est PDG de Cakemail. Ce texte a été écrit après plusieurs mois à construire avec Claude Code et à réaliser que les compétences développées n'avaient rien à voir avec le code.