Donner ses clés à un prestataire IA : la confiance est le vrai contrat

Un accès administrateur au CRM. Les clés API de l’outil de facturation. Le compte qui envoie les emails commerciaux. Des jetons d’accès (les fameux tokens) pour chaque filiale, pays par pays. Voilà ce qu’on remet à un prestataire IA quand on lui demande de construire ses automatisations. À moi, en l’occurrence. Pas un extrait anonymisé, pas un environnement de démonstration : les systèmes en service, avec les données dedans.

Ce transfert de clés est en train de se banaliser à grande échelle. Intégrer l’IA en entreprise est devenu un métier à part entière, les laboratoires y investissent des milliards, et chaque mission de ce métier commence par le même geste : le client ouvre ses systèmes à quelqu’un d’extérieur. On parle beaucoup du prix de ces prestations, de leur retour sur investissement, des modèles qu’elles mobilisent. On parle très peu du moment où un dirigeant tend ses accès à une personne qu’il connaît depuis trois semaines.

Un token donné est un token oublié

Dans un grand groupe, une direction des systèmes d’information tient le registre des habilitations, impose des dates d’expiration, coupe les comptes des prestataires sortis. Dans la plupart des entreprises où j’interviens, rien de tout cela n’existe. Je demande un accès, on me le donne dans l’heure, souvent plus large que nécessaire parce que c’est plus rapide à configurer. Puis la mission suit son cours, se termine. Et le jeton continue de fonctionner.

La vérité inconfortable, la voici : si je ne révoque pas moi-même mes accès en fin de mission, ou si je ne demande pas explicitement qu’on le fasse, je garde la main indéfiniment. Personne ne s’en apercevra, parce que personne ne tient la liste. Ce n’est la faute de personne en particulier : il n’y a simplement pas de poste, pas de rituel, pas de case dans l’organisation où cette responsabilité habite.

J’écrivais récemment que les entreprises protègent leurs données du mauvais risque : elles redoutent qu’un modèle apprenne de leurs fichiers, un scénario largement fantasmé, pendant que l’exposition réelle passe par d’autres portes. Le raisonnement se prolonge ici, à l’étage au-dessus. La bonne question n’est pas « qu’est-ce que l’IA retient de mes données ? ». C’est « qui détient mes clés, depuis quand, et qui le sait ? ».

Le prestataire IA qui demande tout fait juste son métier

La conclusion réflexe serait de fermer les vannes : droits au compte-gouttes, environnements cloisonnés, validation à chaque étape. Ce serait se tromper de leçon.

Construire une automatisation est un travail empirique. La documentation d’une API ne dit jamais toute la vérité. Les données réelles sont toujours plus désordonnées que ce que le client décrit. Le processus qu’on croit linéaire cache trois exceptions que seul le terrain révèle. La bonne architecture ne se déduit pas sur le papier : elle se découvre en touchant le système, en testant, en se trompant vite. Et l’IA ne dispense pas de cette confrontation : elle propose des solutions avec beaucoup d’aplomb, y compris quand elle se trompe, et c’est l’essai grandeur nature qui tranche.

Des droits taillés au strict minimum, arrêtés d’emblée par quelqu’un qui ignore ce qui sera construit, cassent précisément cette boucle. Chaque permission manquante devient un ticket, chaque ticket une journée perdue, et la mission s’enlise dans l’administratif au lieu de produire. Le prestataire qui demande des accès étendus ne fait pas preuve de légèreté. Il fait son travail : rapprocher l’IA d’une réalité métier suppose la liberté d’explorer cette réalité.

L’accès large est donc la matière première du métier. Ce qui doit se discuter, ce n’est pas son étendue, c’est sa durée de vie. Un accès étendu pendant deux jours, sur un compte au nom du prestataire, expose moins qu’un droit modeste oublié trois ans sur un compte partagé. Le danger n’est pas celui qui demande beaucoup : c’est l’accès qui survit à la mission.

La confiance n’est pas un pis-aller, c’est le modèle de sécurité

Puisque l’accès est nécessairement large et que la gouvernance n’existe pas, le seul verrou qui reste est le choix de la personne à qui l’on ouvre. Ce n’est pas une doctrine, c’est un état des lieux : en attendant que les entreprises s’organisent, la confiance fait office de système. Le contrat et les clauses de confidentialité posent le décor juridique, indispensable en cas de litige. Mais au quotidien, ce qui protège réellement vos systèmes, c’est le professionnalisme de celui qui tient vos clés. Sa compétence, pour ne pas casser ce qu’il touche. Son hygiène, pour savoir ce qu’il détient.

Un professionnel se reconnaît à des gestes simples. Il tient de son côté la liste de ce qu’on lui a confié. Il signale un accès devenu inutile au lieu de le laisser dormir. Il demande la révocation en fin de mission, même quand personne ne la lui réclame. Il distingue ce qu’il peut tester librement de ce qui touche à la production. Aucun de ces gestes ne figure dans un devis. Tous font la différence entre un partenaire et un risque.

C’est exactement le sens du mouvement de fond du marché : quand Anthropic finance une société de services dédiée au déploiement de l’IA, il ne vend pas des journées d’ingénieur. Il vend de la confiance organisée, des équipes dont le métier est d’entrer dans les systèmes des autres sans y semer le désordre. La sélection du partenaire n’est pas une ligne parmi d’autres dans l’appel d’offres. C’est la décision de sécurité principale.

Quatre réflexes qui tiennent sur un post-it

Il n’est pas nécessaire d’attendre d’avoir une direction informatique pour reprendre la main. Quatre habitudes suffisent, et elles ne coûtent rien.

Créer un compte propre au prestataire. Jamais les identifiants personnels d’un salarié ou du dirigeant : un compte à son nom, avec ses propres clés. Le jour où la mission s’arrête, on coupe ce compte, et personne d’autre n’est touché.

Noter chaque accès au moment où on le remet. Un tableau à trois colonnes : quel système, quelle personne, quelle date. Trente secondes par accès, et le registre que personne ne tenait existe.

Poser une date de revue en fin de mission. Le jour où le projet se termine, on reprend le tableau ligne par ligne : ce qui sert encore reste, tout le reste se révoque. Sans cette date, la revue n’arrive jamais.

Interroger le prestataire sur sa propre hygiène. « Tenez-vous la liste de mes accès ? Me direz-vous quand vous n’en aurez plus besoin ? » La réponse en dit plus long qu’une certification. Celui qui répond en montrant son registre est celui à qui vous pouvez ouvrir grand. C’est la même logique qui rend utile un pilote de l’IA en interne, même à temps partiel : quelqu’un chez vous dont c’est le rôle de savoir qui détient quoi.

Toute une organisation du travail autour de l’IA reste à inventer dans les entreprises : qui donne les accès, qui les suit, qui les reprend. Elle viendra, comme sont venues les chartes informatiques et les politiques de mots de passe. En attendant, votre sécurité tient à une page de registre et à une décision : la personne que vous choisissez. Le jour où votre prestataire vous écrit « révoquez ce jeton, je n’en ai plus besoin » sans que vous ayez rien demandé, vous saurez que vous avez choisi la bonne.