Le premier chantier d'un Chief of Staff IA n'est pas le modèle, c'est l'identité de chaque agent

Je passe mes journées avec des CEO et des ops leads qui veulent un Chief of Staff IA. La première question qui revient est toujours la même: «quel modèle choisir, GPT, Claude, un modèle maison?». C'est la mauvaise question en premier.

La bonne question est: «quel agent agit, sur quel système, avec quels droits, et qui répond quand ça dérape?». Tant qu'on n'a pas répondu, financer un modèle plus puissant revient à donner une carte de crédit sans plafond à un stagiaire dont on ignore le nom.

Les chiffres récents disent la même chose. 82% des entreprises ont déjà déployé des agents IA, mais 44% n'ont pas de politique de sécurité adéquate autour d'eux. 53% des organisations ont déjà subi ou soupçonné un incident de sécurité lié à l'IA, et 91% n'ont qu'une visibilité limitée — voire nulle — sur les identités de leurs propres agents.

Ce n'est pas un problème de modèle. C'est un problème d'identité.

Prenons un cas que je vois chaque semaine. Un fondateur branche un agent sur Gmail pour préparer ses réunions, un autre sur HubSpot pour mettre à jour les opportunités après les calls, un troisième sur Linear pour ouvrir des tickets à partir des notes Notion. Trois agents, parfois trois fournisseurs différents, souvent connectés via le même token OAuth personnel du fondateur.

Résultat: si l'un d'eux modifie un deal à 80 000 € dans Pipedrive ou envoie un message via un compte Slack, le log dit «agissait au nom de Marc, le CEO». Pas «agent X, version 1.2, déclenché par tel workflow, autorisé jusqu'à tel montant».

Marc ne sait plus qui a fait quoi. Son DAF non plus. Et le jour où un agent hallucine une facture Stripe ou répond à un client à la place d'un commercial, il n'y a personne à appeler, parce qu'il n'y a personne d'identifié.

C'est exactement la situation qu'un Chief of Staff humain ne tolérerait jamais. Un bon CoS sait toujours qui a envoyé quoi, sous quelle autorité, avec quel mandat. C'est ce niveau de discipline qu'il faut câbler dans la couche IA avant tout le reste.

Traçabilité. Sans identité unique par agent, impossible d'auditer une action, d'attribuer une responsabilité, ou d'enquêter sur un incident. 86% des professionnels estiment qu'on ne peut pas faire confiance à un agent IA sans identité numérique propre et dynamique. Et ils ont raison: la confiance opérationnelle se construit sur la possibilité de remonter chaque action à un acteur précis.

Sécurité. Les systèmes IAM classiques ont été conçus pour des humains qui se connectent quelques fois par jour. Les agents IA, eux, sont éphémères, multiples, et s'authentifient des milliers de fois par heure. Sans identité dédiée, on ne peut ni appliquer le principe du moindre privilège, ni révoquer instantanément les droits d'un agent compromis. La fenêtre entre découverte et exploitation d'une vulnérabilité est passée d'années à quelques heures — les contrôles d'identité doivent fonctionner en temps réel.

Conformité. L'AI Act européen est en vigueur depuis 2025, avec des amendes pouvant atteindre 7% du chiffre d'affaires mondial. Pour démontrer la conformité, il faut produire des pistes d'audit montrant qui a fait quoi, quand, et pourquoi. Sans framework d'identité, c'est impossible.

Contrôle opérationnel. La vraie mission d'un Chief of Staff IA, c'est de garantir que l'organisation reste décisionnaire alors que les systèmes agissent à une vitesse qu'aucun humain ne peut superviser en direct. Cela n'a rien à voir avec le choix d'un modèle. C'est une doctrine de gouvernance qui doit être posée avant le déploiement à grande échelle.

J'ai vu plusieurs équipes faire le même chemin. On commence par tester un agent impressionnant sur la préparation de réunions. Ça marche. On l'étend au suivi de décisions. Ça marche encore. On le branche sur HubSpot, sur Stripe, sur Calendly. Et puis un jour, un agent envoie un lien de paiement à un mauvais client, ou modifie le statut d'un deal en pipeline avec une fausse note de call.

Là, on découvre trois choses désagréables. Un: on ne sait pas exactement quel agent a agi, parce qu'ils partagent tous le même compte de service. Deux: on ne peut pas révoquer les droits d'un seul agent sans casser les autres. Trois: les modèles sont interchangeables, on peut passer de l'un à l'autre, mais l'infrastructure d'identité, elle, doit déjà être là — et elle n'y est pas.

La leçon est dure mais simple. Les modèles changent tous les six mois. L'identité, elle, est l'ossature qui doit survivre aux changements de modèles, de fournisseurs et de cas d'usage. Construire dans le mauvais ordre, c'est s'engager à tout refaire.

Voici ce que je conseille aux CEO et COO avant qu'ils ne signent un contrat avec un fournisseur d'agents IA, ou qu'ils ne lancent un déploiement interne.

Inventaire. Listez chaque agent, chaque automatisation, chaque copilote qui touche déjà à vos systèmes sensibles — Gmail, Outlook, Slack, HubSpot, Pipedrive, Linear, Notion, Stripe. Y compris les agents «shadow» que vos équipes ont branchés sans vous prévenir. Vous serez surpris.

Propriétaire humain. Chaque agent doit avoir un humain ou une équipe responsable. Pas «l'IT», pas «l'IA». Un nom. C'est cette personne qui répond en cas d'incident et qui valide les changements de périmètre.

Identité unique et vérifiable. Chaque agent reçoit son propre identifiant cryptographique — certificat, token, clé. Plus de tokens OAuth personnels partagés. Quand un agent agit dans HubSpot, le log montre l'agent, pas le fondateur.

Moindre privilège et autorisation en temps réel. Un agent qui prépare des réunions n'a pas besoin d'écrire dans Stripe. Un agent qui qualifie des leads n'a pas besoin de supprimer des contacts. Les droits doivent être ajustés dynamiquement selon le contexte, et chaque action vérifiée à l'exécution.

Journalisation continue. Toutes les actions sont loguées et auditables. Pas seulement pour la conformité — pour pouvoir détecter rapidement qu'un agent se comporte étrangement avant que ça ne coûte un client.

Ce travail prend deux à six semaines selon la maturité. Il coûte moins cher que le premier incident.

Chez Moments, on construit un Chief of Staff IA branché sur l'email, le calendrier, les contacts, les documents et le navigateur du dirigeant. Concrètement, ça veut dire qu'on est exactement le type d'agent dont je parle dans ce billet: avec un fort accès, en continu, sur des données sensibles.

C'est pour ça qu'on traite l'identité de l'agent comme une question de produit, pas comme un détail technique. Chaque action est attribuable, chaque permission est explicite, et on dit clairement où l'agent peut agir seul et où il doit demander.

Je ne vais pas prétendre que c'est résolu pour tout le monde. La plupart des fournisseurs d'agents que je vois sur le marché aujourd'hui — y compris les plus connus — vendent encore le modèle avant l'identité. C'est à vous, en tant qu'opérateur, de poser les bonnes questions avant de signer: qui agit sous mon nom, quels logs je peux exporter, comment je révoque un agent en trente secondes si besoin.

Si le fournisseur répond «notre modèle est très performant», changez de fournisseur.

Un Chief of Staff humain protège la bande passante du dirigeant et garantit que les décisions prises sont exécutées proprement. Un Chief of Staff IA doit faire la même chose, plus une chose en plus: garantir que la chaîne d'autorité reste lisible alors que les exécutants ne sont plus humains.

Ça veut dire cartographier les frontières d'autonomie de chaque agent. Ça veut dire intégrer les contrôles d'identité dans les workflows réels — pas dans un document de gouvernance que personne ne lit. Ça veut dire accepter que la première livraison du programme IA ne soit pas un démo bluffant, mais un registre d'agents avec leurs propriétaires, leurs droits et leurs logs.

C'est moins sexy qu'un agent qui rédige des emails brillants. C'est ce qui décide si, dans deux ans, votre déploiement IA tient encore debout ou s'est effondré sous le poids d'un incident qu'on aurait pu attribuer — si seulement on avait su à qui.