7 min de lectureTout fonctionne. Jusqu’au jour où il faut changer quelque chose.
L’automatisation tourne depuis dix-huit mois, et personne n’y pense vraiment. C’est généralement le plus beau compliment qu’on puisse lui faire.
Puis un collaborateur quitte l’entreprise. Son adresse email était administratrice du compte. Le scénario repose sur une clé API créée depuis son profil personnel. Personne ne connaît le mot de passe du service intermédiaire. Quant à la documentation, elle tient en trois captures d’écran perdues dans une vieille conversation.
Et soudain, tout le monde s’intéresse de très près à la gouvernance.
Ce scénario n’a rien d’exceptionnel. Beaucoup d’automatisations naissent comme des expérimentations : construites vite, elles prouvent leur utilité, puis deviennent peu à peu indispensables sans jamais passer par la cérémonie officielle qui en ferait un véritable actif de l’entreprise.
Elles grandissent discrètement dans un coin. Comme un ficus, mais avec davantage de jetons d’accès.
Utiliser un système n’est pas la même chose que le maîtriser
Une entreprise peut payer chaque mois une solution et dépendre entièrement d’une personne extérieure pour la comprendre. Elle peut posséder les données sans savoir les exporter. Détenir le compte principal sans connaître aucune des dépendances. Avoir le code source et être incapable de le déployer. Ou disposer d’une documentation complète datant de trois ans, ce qui est parfois une manière très sophistiquée de ne pas avoir de documentation.
L’autonomie tient donc moins à une propriété théorique qu’à une question très concrète :
L’entreprise peut-elle comprendre son système, en reprendre l’exploitation et choisir librement de le faire évoluer ?
Si la réponse est non, il existe une dépendance. Elle n’est pas forcément problématique. Il faut simplement la connaître, l’accepter en conscience et prévoir ce qui se passera si la situation change.
Commencez par les choses peu romantiques : comptes, accès et clés
Qui possède le compte principal de la plateforme ? Existe-t-il plusieurs administrateurs ? Les comptes sont-ils nominatifs ? Une authentification forte est-elle activée ? Où sont stockées les clés API, et qui peut les créer ou les révoquer ? Quelqu’un qui est parti il y a six mois a-t-il encore un accès ?
Ces sujets font rarement l’affiche d’une conférence sur l’innovation. Ils déterminent pourtant la capacité de l’entreprise à reprendre la main.
La CNIL rappelle que les traitements confiés à un sous-traitant doivent s’accompagner de garanties suffisantes, notamment sur l’authentification, la gestion des habilitations, la traçabilité, les incidents et la restitution des données en fin de contrat. Sa fiche sur la sécurité de la sous-traitance détaille ces précautions.
Ce n’est pas qu’une question de réglementation. C’est de l’hygiène opérationnelle. Un workflow critique dont l’unique compte administrateur est une adresse personnelle raconte déjà une histoire, et elle finit rarement bien.
Il faut distinguer le propriétaire métier du propriétaire technique
Une automatisation peut avoir plusieurs responsables.
Le propriétaire métier décide :
- pourquoi le processus existe ;
- quelles règles doivent s’appliquer ;
- quel résultat est attendu ;
- quelles exceptions nécessitent une intervention ;
- quel niveau de risque est acceptable.
Le propriétaire technique sait :
- où le workflow est hébergé ;
- quelles intégrations il utilise ;
- comment surveiller son fonctionnement ;
- comment renouveler un secret ;
- comment reprendre après une erreur ;
- comment déployer une modification.
Dans une petite structure, une seule personne peut tenir les deux rôles. Il faut quand même les expliciter. Sans cela, l’équipe technique croit que le métier surveille le résultat, pendant que le métier suppose que la technique comprend la règle. Tout le monde est rassuré, et personne ne regarde tout à fait la même chose.
Vos données doivent pouvoir sortir
La dépendance saute aux yeux le jour où l’on veut changer de solution.
Peut-on exporter les données ? Dans quel format ? Avec leur historique, leurs métadonnées, les relations entre objets ? Et une fois les données sorties, a-t-on vraiment de quoi reconstruire le fonctionnement ailleurs ?
Le règlement européen sur les données, le Data Act, applicable depuis le 12 septembre 2025, contient des dispositions pour faciliter le changement entre services de traitement de données. Il prévoit notamment que les offres concernées de type SaaS et PaaS proposent des interfaces ouvertes et permettent l’export dans un format courant, lisible par machine. Les frais liés au changement de fournisseur doivent disparaître à partir du 12 janvier 2027. La Commission européenne présente ces mesures dans son explication du Data Act.
La réglementation va donc dans le sens de la réversibilité. Mais une entreprise n’a pas à attendre une séparation conflictuelle ou un texte de loi pour se poser une question toute simple :
Si nous arrêtons ce service demain, que récupérons-nous réellement ?
La réponse est plus confortable quand on la connaît avant la rupture.
Le code source ne suffit pas
« Nous possédons le code » semble tout régler. Pas vraiment.
Le système dépend peut-être :
- d’une version particulière d’un langage ;
- de services externes ;
- d’un modèle d’IA ;
- d’une base de données ;
- de variables d’environnement ;
- de clés d’accès ;
- d’un script de déploiement ;
- d’un hébergement configuré d’une manière que personne n’a décrite.
Un dossier compressé contenant le code ne garantit donc pas qu’on saura relancer l’application. La propriété utile comprend aussi :
- les instructions de déploiement ;
- la liste des dépendances ;
- les accès ;
- les données ;
- les paramètres ;
- les procédures de sauvegarde et de restauration.
L’entreprise n’a pas besoin de maîtriser chaque ligne. Elle doit pouvoir confier l’ensemble à quelqu’un d’autre sans repartir de fouilles archéologiques.
Les données confiées à un prestataire restent une responsabilité de l’entreprise
Externaliser un traitement ne fait pas disparaître les obligations qui vont avec. Quand un prestataire traite des données personnelles pour le compte de l’entreprise, celle-ci doit notamment s’assurer des garanties de sécurité, encadrer la relation par contrat et comprendre la chaîne de sous-traitance. La CNIL insiste sur le partage des responsabilités, les conditions de restitution ou de destruction des données, la notification des incidents et la vérification des mesures de sécurité. Ces points figurent dans ses recommandations aux responsables de traitement.
Avec l’IA, la question devient encore plus importante, car les informations peuvent circuler entre plusieurs acteurs :
- plateforme d’automatisation ;
- fournisseur du modèle ;
- base de données ;
- outil métier ;
- connecteur tiers ;
- hébergeur.
Comprendre le flux technique, c’est aussi comprendre qui reçoit quoi, à quel titre et pendant combien de temps.
Une documentation utile n’est pas un roman
Les équipes détestent documenter. Les systèmes évoluent, la documentation vieillit, et la stratégie la plus rationnelle semble alors de ne rien écrire. Curieusement, cela pose ensuite quelques difficultés.
La solution n’est pas forcément de rédiger cent vingt pages que personne ne maintiendra. Pour une automatisation classique, quelques éléments peuvent suffire :
- son objectif ;
- son déclencheur ;
- les systèmes utilisés ;
- les comptes et propriétaires ;
- les règles importantes ;
- les principales exceptions ;
- la manière de l’arrêter ;
- la procédure de reprise manuelle ;
- l’endroit où regarder quand elle échoue.
Une documentation doit répondre à une question :
Une autre personne peut-elle comprendre suffisamment le système pour ne pas être totalement démunie ?
Si oui, elle fait son travail. On lui pardonnera volontiers l’absence de sommaire interactif.
L’autonomie ne signifie pas tout faire soi-même
Une entreprise n’a aucune obligation de maîtriser toutes les compétences techniques. Elle externalise déjà sa comptabilité, son infrastructure, une partie de son juridique ou de son développement.
Le problème n’est pas de dépendre d’une compétence. Le problème, c’est la dépendance invisible, non documentée et impossible à remettre en cause.
Une relation avec un prestataire peut très bien durer dix ans tout en laissant l’entreprise maîtresse de ses choix. Les comptes sont correctement structurés, les données sont récupérables, les décisions techniques sont explicables, la documentation existe, et les connaissances essentielles ont été transmises. Si un jour les deux parties veulent arrêter de travailler ensemble, personne n’a à négocier la libération d’un fichier retenu en otage.
C’est une situation plutôt saine.
Le véritable test de propriété
Pour savoir si votre entreprise maîtrise vraiment une automatisation, imaginez que son créateur devienne indisponible demain. Pas mort, ne dramatisons pas. Il est simplement parti faire autre chose.
Pouvez-vous :
- comprendre ce que fait le système ;
- accéder à ses composants ;
- identifier les données utilisées ;
- voir quand il échoue ;
- révoquer ses accès ;
- récupérer les informations ;
- restaurer une sauvegarde ;
- le faire reprendre par quelqu’un d’autre ?
Si oui, vous possédez probablement votre automatisation au sens qui compte. Si non, ce n’est pas une catastrophe : vous venez d’identifier un chantier. Et il vaut bien mieux le découvrir aujourd’hui que le matin où la personne concernée vous envoie une photo de chèvre depuis le Larzac.