Pourquoi l'autonomie d'un Chief of Staff IA doit se mesurer en paliers, pas en tout-ou-rien

J'ai vu ce schéma se répéter chez des dizaines d'opérateurs qui adoptent un Chief of Staff IA. Les deux premières semaines, tout passe par validation humaine. Puis, dès que trois ou quatre réponses tombent juste, le réflexe est le même: "ok, tu peux gérer ça toute seule maintenant". On bascule d'un coup vers l'exécution autonome, sur l'ensemble des tâches, sans distinction.

C'est exactement l'erreur que pointe Colin Dargent dans son analyse de la calibration d'agents IA: l'autonomie n'est pas un interrupteur, c'est un curseur. Et un curseur, ça se règle progressivement, pas d'un geste.

Le problème n'est pas la confiance excessive en soi. C'est que la confiance se construit sur une expérience partielle — quelques emails bien triés, un compte-rendu de réunion correct — et se généralise à tort à des tâches beaucoup plus sensibles, comme l'envoi d'un message à un investisseur ou la modification d'une deal dans le CRM.

Le framework développé par Dargent après plus de trente missions en PME propose cinq niveaux distincts. L0, le copilote: l'IA assiste, l'humain réécrit tout. L1, le brouillon: l'IA produit, l'humain corrige. L2, la revue: l'IA livre, l'humain ne contrôle que les sections risquées. L3, l'autonomie supervisée: seules les exceptions remontent. L4, l'autonomie complète: aucun humain dans la boucle, sauf erreur détectée.

Ce qui rend ce cadre solide, ce n'est pas la liste des niveaux — c'est le critère de passage entre eux. Dargent propose un ratio A/R, le nombre de corrections par exécution, et fixe un seuil clair: on ne monte de palier que si ce ratio reste sous 0,5 pendant quatre semaines consécutives. Pas d'impression, pas de "ça a l'air de bien marcher". Une mesure.

Appliqué à un Chief of Staff IA connecté à Gmail, à l'agenda et au CRM, ça donne quelque chose de concret: la lecture et le tri d'inbox peuvent atteindre L3 en quelques semaines parce que les erreurs y sont visibles et réversibles. La rédaction de réponses à des prospects HubSpot ou Pipedrive stagne plus longtemps en L1-L2, parce qu'une erreur de ton ou de fait y coûte une relation commerciale. Et la modification d'un statut de deal, l'envoi d'un contrat, la programmation d'un paiement Stripe — ça, ça ne quitte pas la supervision humaine avant d'avoir prouvé, sur la durée, une fiabilité quasi parfaite.

La distinction qui compte vraiment n'est pas lecture contre action. C'est réversible contre irréversible. Un agent qui résume un thread Slack mal interprété, ce n'est pas grave — on relit, on corrige, ça n'a coûté qu'une minute. Un agent qui envoie une relance commerciale erronée à un client, ou qui modifie une échéance dans Linear en cascade sur trois équipes, ça, ça a des conséquences qui survivent à la correction.

C'est pour ça que je pousse toujours mes clients à définir des paliers distincts par type de tâche, pas un palier global pour "l'agent". Une IA peut être en L3 sur le tri de calendrier et rester en L1 sur la rédaction d'emails sensibles au même moment. Ce n'est pas de l'incohérence, c'est de la granularité bien pensée.

Les cas documentés qui fonctionnent suivent cette logique. Klarna n'a pas basculé son agent de support sur 100% du trafic du jour au lendemain — ils ont pilote à 10%, suivi des KPIs quotidiens, et scalé seulement après avoir franchi des seuils de performance stricts. Résultat: 40 millions de dollars d'économies annuelles, sans dégradation de la satisfaction client. Octopus Energy fait pareil: l'agent gère 33% du support, et la revue humaine se concentre exclusivement sur les sorties à haut risque. Full autonomy réservée aux workflows à faible risque, prouvés dans le temps.

Le risque n'est pas que l'agent se trompe une fois. C'est qu'il se trompe en silence, sur une base large, avant que quiconque ne s'en aperçoive. Quand on saute un palier de supervision, on perd le mécanisme même qui aurait détecté la dérive.

Pour un Chief of Staff IA, les cas d'échec ne sont pas abstraits: diffuser des priorités mal alignées à une équipe, mal gérer une information confidentielle partagée par email, ou ne pas escalader un signal critique qui aurait dû remonter à un fondateur. Le rôle touche à la gouvernance, à la coordination transverse, à l'intermédiation entre l'intention du dirigeant et l'exécution opérationnelle — ce n'est pas un poste où l'erreur reste locale.

Un autre point sous-estimé: un taux de correction élevé n'indique pas toujours une IA incompétente. Souvent, c'est le signe que la spécification de la tâche était floue. Avant de parler d'autonomie, il faut des specs claires, puis des KPIs pour les mesurer, et seulement ensuite de l'autonomie. Inverser cet ordre, c'est confondre la vitesse d'exécution avec la fiabilité.

Chez Moments, on ne construit pas l'autonomie comme un curseur unique qu'on avance à mesure que la confiance grandit vaguement. On la découpe par domaine: lecture d'inbox et de calendrier, rédaction de brouillons, actions réversibles comme le classement d'un contact HubSpot, actions irréversibles comme l'envoi d'un email externe ou la modification d'un deal Pipedrive. Chaque domaine progresse à son rythme, avec ses propres critères de passage.

Concrètement, ça veut dire logger chaque correction, pas dans la mémoire du manager mais dans un fichier de spécifications vivant. Ça veut dire une revue hebdomadaire des métriques de l'agent plutôt qu'une impression générale de "ça marche bien en ce moment". Et ça veut dire accepter qu'un agent puisse rester bloqué en supervision sur une tâche pendant des mois, tant que le seuil de fiabilité n'est pas atteint — même si, sur d'autres tâches, il tourne déjà en quasi-autonomie complète.

Ce n'est pas de la bureaucratie. C'est la seule façon de savoir, avec des données et pas avec du feeling, à quel moment on peut vraiment lâcher la main sur une tâche donnée.