Restez propriétaire de votre système : les sept questions à poser à votre prestataire

Rester propriétaire de votre système tient à sept questions posées avant de signer : ce que vous récupérez en partant, sous quel format, où vivent les accès, et si un autre prestataire peut reprendre sans appeler le premier. Un prestataire qui y répond par écrit vous vend un système ; celui qui les élude vous vend une dépendance.

Le jour où vous voulez partir, vous découvrez que vous ne pouvez pas

Le dirigeant connaît ce moment, même s'il ne l'a pas encore vécu : un jour, il veut changer de prestataire. Les tarifs ont augmenté, les délais s'allongent, le courant passe moins bien, ou le prestataire annonce qu'il arrête son activité. Une décision simple, en apparence : on prévient, on récupère ses affaires, on confie la suite à quelqu'un d'autre. Puis la réalité apparaît, pièce par pièce. Les accès administrateurs sont au nom du prestataire. Les données s'exportent, mais en morceaux, sans l'historique. Les automatisations tournent sur son compte, avec ses clés. Les procédures, quand elles existent, sont écrites dans son outil, pas dans le vôtre. Et le nom de domaine, parfois, a été déposé par lui, pour vous arranger à l'époque.

Chaque point pris isolément semble un détail réglable. Ensemble, ils forment un verrou. Le nouveau prestataire demande la documentation : il n'y en a pas, ou elle est trop sommaire pour reprendre sans appeler l'ancien. L'ancien, lui, n'a aucune raison de se presser : chaque semaine de transition facturée est une semaine de chiffre pour lui. Alors le changement, prévu pour durer un mois, s'étire sur un trimestre, coûte deux fois le budget annoncé, et se termine souvent par un renoncement : on reste, faute de pouvoir partir. L'entreprise n'a pas choisi son prestataire ce jour-là ; elle a constaté qu'elle ne pouvait plus le quitter.

Le plus trompeur est que rien, pendant la collaboration, ne laissait présager ce blocage. Le système fonctionnait, les livraisons arrivaient, la relation était cordiale. C'est normal : une dépendance ne se voit jamais quand tout va bien, elle ne se révèle qu'au moment de la sortie. D'où le conseil de cet article, qui tient en une phrase : la propriété de votre système se décide avant le premier rendez-vous, pas après. Vos données, votre mémoire, vos procédures et vos automatisations vous appartiennent par principe ; encore faut-il que le contrat, les accès et les formats le garantissent dans les faits. Sept questions posées à temps suffisent à faire la différence entre un système que vous possédez et un système que vous louez sans le savoir.

La propriété ne se négocie pas à la sortie, elle s'écrit à l'entrée

Il faut d'abord nommer ce qui doit vous appartenir, parce que la plupart des dirigeants ne le voient jamais écrit noir sur blanc. Ce n'est pas seulement « les données », mot vague qui finit par tout désigner et ne protéger rien. Ce sont cinq actifs précis : vos données avec leur historique ; les accès administrateurs de tous les comptes ouverts pour vous ; la mémoire de l'entreprise, c'est-à-dire les procédures, les décisions et les notes qui font tourner le système ; les automatisations elles-mêmes, avec leurs schémas et leurs réglages ; et les titres, nom de domaine et hébergements déposés à votre nom. Quand ces cinq actifs vivent chez vous, dans vos outils et sous vos comptes, changer de prestataire est une formalité. Quand l'un d'eux vit chez lui, c'est une négociation.

Le tableau suivant sert de boussole : pour chaque actif, il dit où il doit vivre et quelle preuve vous devez pouvoir produire un jour quelconque, sans prévenir personne. Si vous ne pouvez pas produire la preuve aujourd'hui pour l'une des lignes, c'est cette ligne qu'il faut régulariser en premier, avant même de parler de nouveaux projets :

Cette exigence n'est pas une méfiance envers les prestataires, c'est une méthode de construction. Notre méthode C.A.P. la pose au moment d'architecturer : une fois le fonctionnement réel cartographié, on décide de quoi l'entreprise doit se souvenir pour bien fonctionner, puis on tranche où vit réellement chaque information, entre les outils métiers et la mémoire de l'entreprise, avant de classer chaque tâche selon qu'elle relève d'une règle, d'un agent ou d'un humain. Un système construit ainsi est réversible par conception, parce que chaque actif a un propriétaire nommé dès l'origine. Et cette logique ne date pas d'hier : du Zettelkasten du sociologue Niklas Luhmann, qui conservait chaque fiche dans un ordre retrouvé des années plus tard, aux carnets de décisions d'architecture du génie logiciel, qui consignent chaque choix avec son contexte pour l'équipe qui relira le code dans deux ans, les organisations qui durent sont celles dont la mémoire survit à ceux qui l'ont écrite.

Les sept questions de réversibilité, à poser telles quelles

Voici le livrable de cet article : sept questions à recopier telles quelles et à envoyer à tout prestataire avant le premier rendez-vous, en exigeant une réponse écrite. L'ordre compte : on part de ce que vous récupérez, on finit par le pire des cas. Un prestataire sérieux répond en quelques jours, avec des précisions ; un prestataire qui refuse d'y répondre, les juge excessives ou promet de « voir ça plus tard » en dit plus long sur la suite qu'un prestataire qui accepte.

1. Si nous nous séparons demain, que récupérons-nous exactement, et sous quel format lisible sans vos outils ? La bonne réponse nomme chaque élément, fichiers clients, historique, procédures, réglages, et un format ouvert que n'importe quel successeur saura ouvrir. Une réponse qui parle de « vos données » sans liste ni format ne garantit rien.
2. Où sont les accès administrateurs, et qui les détient aujourd'hui ? Noms de domaine, hébergements, comptes des outils, clés des automatisations : la bonne réponse montre des comptes à votre nom avec les droits les plus élevés. Tout accès que vous ne détenez pas est un actif que vous ne possédez pas.
3. Pouvons-nous exporter nos données en entier, avec leur historique, sans votre intervention ? La bonne réponse décrit la manoeuvre, où cliquer, ce que contient l'export, et confirme que l'historique suit. Si l'export exige une demande d'assistance, un devis ou une manipulation de son côté, la sortie dépend de son bon vouloir.
4. Les procédures et la mémoire du système sont-elles écrites dans nos outils, pas seulement dans les vôtres ? La bonne réponse désigne l'endroit, votre mémoire d'entreprise, rédigée en langage courant, tenue à jour à chaque livraison. Une documentation qui vit dans son espace de travail part avec lui.
5. Quelles parties dépendent de licences ou d'abonnements à votre nom, et que se passe-t-il si on les arrête ? La bonne réponse liste chaque abonnement, son titulaire et l'effet d'un arrêt. Ce qui tourne grâce à ses licences s'arrête le jour où vous partez, sauf transfert prévu.
6. Un autre prestataire peut-il reprendre le système avec la documentation seule, sans vous appeler ? C'est la question décisive. La bonne réponse dit oui et désigne la documentation qui le permet. Toute reprise qui suppose « quelques appels » ou « une passation » suppose surtout sa disponibilité et sa bonne volonté.
7. Que devient le système si vous cessez votre activité ? La bonne réponse décrit le plan de continuité : qui peut faire tourner quoi, avec quels accès, pendant combien de temps. Un prestataire individuel sans réponse à cette question fait porter à votre entreprise son propre risque personnel.

Ce que ça change chez vous

Pour le dirigeant, le changement se mesure le jour où il faut trancher. Avec des réponses écrites aux sept questions, chaque décision, renégocier, changer de prestataire, reprendre en interne, se prend sur des faits : on sait ce que l'on récupère, sous quel format, avec quels accès, et ce que la sortie demande comme travail. Sans elles, chaque décision se prend à l'aveugle, et l'aveugle finit toujours par rester. Côté coût, une sortie préparée se chiffre avant de s'engager : le temps de reprise est connu, le successeur chiffre sur pièces, et l'ancien ne facture pas sa propre rétention d'information. Côté délai, la transition suit le plan au lieu de s'étirer au rythme des découvertes, parce qu'il n'y a plus de découvertes : tout était écrit. Et la relation elle-même y gagne : un contrat clair protège les deux parties, et les prestataires sérieux préfèrent un client exigeant à l'entrée à un client prisonnier à la sortie.

Pour l'équipe, la propriété du système change le quotidien de ceux qui s'en servent. Des procédures écrites dans la mémoire de l'entreprise, des accès à son nom, des automatisations documentées : chacun sait où trouver l'information et qui peut agir sur quoi, sans passer par un intermédiaire extérieur pour la moindre modification. Le départ d'un salarié clé cesse d'être une catastrophe, parce que le savoir vit dans les notes et pas dans sa tête ; l'arrivée d'un nouveau va plus vite, parce que le système se lit au lieu de se raconter. Et face au prestataire, l'équipe parle d'égal à égal : elle détient les accès, elle produit les exports, elle lit les schémas. La dépendance technique fabrique des exécutants qui subissent ; la propriété partagée fabrique des utilisateurs qui pilotent.

Ce que ça change pour vos agents

Pour vos agents IA, un système dont vous êtes propriétaire est un système qu'ils peuvent lire en entier. Un agent branché sur une mémoire qui vous appartient, des procédures rédigées dans vos outils, des données exportables avec leur historique, répond à partir de la matière en vigueur : il applique la procédure arbitrée, retrouve le contexte des décisions, signale les cas où il lui manque une pièce au lieu d'inventer. Le même agent, branché sur un système loué sans le savoir, travaille sur des reflets : des exports partiels, des procédures hébergées ailleurs, des automatisations dont il ne voit pas les réglages. L'erreur ne sera pas dans le modèle, elle sera dans l'incomplétude de ce qu'on lui donne à lire. Chaque actif que vous récupérez chez vous est une source de plus que l'agent n'aura pas à deviner.

C'est aussi une question de doctrine, celle que nous appliquons à chaque déploiement : automatisation quand une règle suffit, agent IA quand il faut comprendre ou juger, validation humaine quand l'action compte. Cette doctrine suppose un système que vous possédez : les règles que l'on automatise doivent vivre sur vos comptes, la matière dont l'agent a besoin pour juger doit résider dans votre mémoire, et la personne dont la validation compte doit détenir les accès qui permettent d'agir. Côté maintenance, enfin, la propriété simplifie tout : quand chaque actif a un propriétaire nommé et un lieu de vie connu, mettre à jour une règle ou corriger un contexte d'agent est une opération courante, là où un système dispersé entre les outils du prestataire transforme chaque correction en demande d'assistance.

Le mouvement C.A.P. illustré : Architecturer

Ces sept questions appartiennent au deuxième mouvement de notre méthode, Architecturer : une fois le fonctionnement réel cartographié, on construit un système dont l'entreprise reste propriétaire, à commencer par sa mémoire et ses accès. Pour voir comment les trois mouvements s'articulent, rendez-vous sur la méthode C.A.P..

Questions fréquentes