Internaliser les automatisations de ton agence : ce qu'il faut exiger avant de couper

Trois signes que tes automatisations ne t'appartiennent pas, même si tu les paies

La propriété d'un système automatisé ne se décide pas sur la facture. Elle se décide sur l'endroit où il tourne, sur le nom inscrit sur les clés, et sur la capacité de quelqu'un d'autre que son constructeur à le comprendre. Trois signes reviennent toujours, et les trois se vérifient en un après-midi sans prévenir personne.

• Tu ne peux pas entrer seul. Si voir où en est un processus suppose de demander une capture d'écran à quelqu'un, tu n'as pas un accès : tu as un intermédiaire. Le test est littéral — connecte-toi aujourd'hui, sans prévenir, et regarde la dernière exécution.
• Tu ne sais pas ce qu'il décide. Si personne dans ton équipe ne peut expliquer pourquoi tel cas est parti en file de revue et tel autre, similaire, non, la règle métier n'est pas à toi. Elle tourne, mais tu ne la possèdes pas.
• Tu ne peux pas changer de prestataire sans t'arrêter. Si la seule réponse à « et si on arrête le mois prochain ? » est « tout s'arrête », ce que tu as acheté n'est pas un service : c'est une dépendance avec une facture mensuelle.

Aucun des trois ne suppose de la mauvaise foi. La plupart du temps ce sont les séquelles naturelles d'un démarrage rapide : ça a été monté dans le compte de celui qui montait parce que c'était le plus agile, connecté avec les identifiants sous la main, et la règle a été convenue au téléphone. Ça marche. Et ça continue de marcher jusqu'au jour où tu veux le déplacer. D'où la règle : on vérifie quand tout va bien, pas une fois qu'on a décidé de couper.

Le compte et les identifiants : où vit le système et à quel nom

C'est le point le plus souvent sauté et le seul qui, s'il tombe, annule tout le reste. Il y a deux couches et on les confond en permanence : le compte de l'outil où tournent les flux, et les identifiants de chaque service auquel ces flux se connectent.

• Le compte de la plateforme. L'espace de travail Make, l'instance n8n, le projet Zapier. Il doit être sur une adresse de ton domaine —jamais la boîte personnelle de quelqu'un—, avec ton moyen de paiement et au moins deux administrateurs de ton côté. Si le prestataire paie l'abonnement et te le refacture, ce n'est pas le tien.
• Les identifiants de chaque connexion. L'accès à ton CRM, à ton ERP, à la boîte partagée, à la passerelle de paiement. Chacun devrait être créé par toi, idéalement comme compte de service aux droits limités, pas comme le compte personnel d'un consultant qui partira un jour.
• Le domaine et les webhooks. Les URLs vers lesquelles d'autres systèmes te poussent des données. Si elles pointent vers un domaine du prestataire, changer de prestataire oblige à toucher la configuration de tiers, et c'est la partie lente de toute migration.

La vérification honnête tient en une question : si tu changeais le mot de passe administrateur demain, est-ce que tout tournerait encore ? Si la réponse est non, ou que tu ne sais pas, voilà le travail en attente. Et ce n'est pas un travail de négociation : c'est une migration technique de deux jours bien faite, qui laisse en prime tes identifiants inventoriés — exactement ce que réclame tout contrôle sérieux sur ce que l'automatisation a le droit de toucher.

Exporter les flux : ce qu'un fichier emporte et ce qu'il laisse dehors

C'est là que presque tout le monde se détend trop tôt. Tu reçois un fichier JSON avec les flux, tu l'archives et tu considères l'affaire réglée. Le fichier est nécessaire, mais ce n'est pas le système : c'est le plan. Et il y a une partie du plan que les plateformes laissent dehors, par conception.

• Chez Make, le blueprint du scénario est un JSON avec les modules, leurs réglages et les valeurs mappées ; les connexions ne voyagent pas dedans, donc celui qui importe doit ré-autoriser chaque service avec ses propres comptes.
• Chez n8n, le JSON du flux contient le nom et l'identifiant de la credential mais pas son contenu ; les credentials s'exportent à part en ligne de commande, sortent chiffrées et ne se déchiffrent que sur une instance ayant la même clé de chiffrement.
• Partout, ce que le fichier laisse dehors, c'est l'environnement : variables, en-têtes, limites de débit négociées avec un fournisseur, boîtes autorisées à envoyer. C'est la partie qui fait que le même flux marche ici et échoue là-bas.

Donc on n'accepte pas une reprise contre un fichier, on l'accepte contre une exécution. Le test est simple et sans nuance : importer les flux dans un compte à toi et les voir traiter un cas réel de bout en bout, avec tes identifiants, avant que quiconque signe. Si le processus touche de l'argent ou des engagements client, ce test se fait d'abord sur un environnement de test, avec la même discipline que pour tester un changement sans casser l'automatisation.

La règle métier : ce qui n'apparaît dans aucun export

Un flux exporté te dit ce que fait le système. Il ne te dit pas pourquoi. Et le pourquoi, c'est la partie chère : le seuil des 3 000 euros, la liste des cinq clients qui ne passent jamais en validation automatique, la raison pour laquelle les mails d'un domaine précis sont ignorés depuis mars. Rien de tout ça n'est dans le JSON. C'est dans des décisions que quelqu'un a prises sans les écrire.

La façon de le récupérer n'est pas de demander « de la documentation » —ce mot produit des PDF que personne ne lit—. C'est de demander une liste de décisions, un artefact bien plus petit et bien plus utile.

• Chaque bifurcation du flux, avec son seuil et sa raison. Une ligne par « si… alors… » : ce qu'il compare, à quelle valeur, et d'où sort cette valeur.
• Les exceptions nommées. Clients, fournisseurs ou cas traités différemment, et qui a autorisé ce traitement.
• Ce que fait le système quand ça casse. Qui il prévient, ce qu'il retente, ce qu'il met de côté pour un humain.
• Ce qu'il ne fait pas, exprès. La liste de ce qu'on a sciemment laissé dehors est ce qui empêche la nouvelle équipe de « réparer » quelque chose qui allait très bien comme ça.

Si le prestataire ne peut pas produire cette liste en deux heures, ce n'est pas de la mauvaise volonté : c'est que le système n'a jamais été documenté et que la règle vit dans une tête. C'est ton risque, pas le sien, et il se règle avec la méthode utilisée pour documenter une automatisation déjà en production : reconstruire le pourquoi à partir des exécutions réelles, pas de la mémoire.

L'historique d'exécution : l'actif que personne ne demande et que tout le monde regrette

C'est la demande oubliée dans neuf reprises sur dix et celle qui manque le plus un mois plus tard. L'historique —ce qui s'est exécuté, quand, sur quelles données, avec quel résultat— est ce qui transforme une automatisation en quelque chose de mesurable au lieu d'un acte de foi.

• C'est ta ligne de base. Sans savoir combien d'exécutions par jour il y avait et quel pourcentage échouait, tu ne peux pas démontrer que le système internalisé fait aussi bien ou mieux. Tu vas en débattre de mémoire, et la mémoire dit toujours que c'était mieux avant.
• C'est ton détecteur de cas bizarres. Les cas qui cassent un flux ne sont pas dans la documentation : ils sont dans six mois de journaux d'erreurs. Cette liste vaut plus que le manuel.
• Ça expire. La plupart des plateformes ne gardent le détail d'exécution qu'un temps limité selon l'offre. Demandé trois mois après la coupure, il n'existe plus.

Demande-le avant d'annoncer le changement et stocke-le hors de la plateforme : un export du journal, même brut. C'est aussi le matériau qu'il te faut pour savoir ce qui est tombé et ce qu'il faut retraiter si la migration laisse un trou.

Le recouvrement : comment couper sans couper le service

Une reprise bien faite n'a pas de jour J. Elle a une fenêtre pendant laquelle les deux systèmes cohabitent et un seul commande. L'erreur classique va dans l'autre sens : date de fin de contrat, extinction, et l'équipe nouvelle qui découvre à chaud que le flux de facturation avait une condition dont personne n'avait parlé.

• D'abord miroir, ensuite commande. Le nouveau système tourne en parallèle sans écrire en production —ou en écrivant sur une destination de test— et on compare les résultats plusieurs jours. Tout écart s'investigue avant de toucher quoi que ce soit.
• Coupure par tranches, pas d'un bloc. Un flux passe, on vérifie une semaine, on passe au suivant. Le processus qui touche l'argent passe en dernier, jamais en premier.
• L'ancien système s'éteint, ne se supprime pas. Il reste désactivé et accessible pendant tout le recouvrement. Un flux supprimé le jour de la bascule, c'est un pont brûlé avec le seul qui savait comment ça marchait.
• Un cycle complet avant de fermer. S'il y a une clôture mensuelle, le recouvrement en contient une entière. Les cas bizarres n'arrivent pas le mardi : ils arrivent le 30.

La logique est celle de toute migration de plateforme bien posée —c'est exactement la méthode pour passer d'un outil à un autre sans arrêter le service— à une différence près : ici tu ne changes pas seulement d'outil, tu changes de propriétaire de la connaissance. Et cette partie-là ne s'importe pas avec un JSON.

Une note honnête pour finir : internaliser n'est pas toujours la réponse. Rapatrier les flux, c'est quelqu'un chez toi qui prend l'astreinte, les mises à jour d'API et l'entretien continu, soit un vrai travail avec un vrai coût. La bonne question n'est pas « dedans ou dehors ? », c'est « est-ce que ça m'appartient dans les deux cas ? ». Quand la réponse est oui, rester avec un prestataire est une décision économique tranquille. Quand elle est non, tu n'achètes pas un service : tu loues ton propre processus. Si tu veux cette vérification faite par quelqu'un de l'extérieur —inventaire des comptes, export prouvé, règle métier reconstruite et plan de recouvrement—, c'est exactement ce qu'on fait en automatisation des opérations.