La dépendance ne se voit pas au moment où elle s'installe
Personne ne signe un contrat en se disant « tiens, je vais me rendre captif ». La dépendance à un prestataire d'automatisation s'installe par petits glissements. Un workflow ici, une intégration là, un accès API que seul le prestataire connaît. Six mois plus tard, tu réalises que la personne qui comprend comment ta facturation tourne n'est pas dans tes murs.
Ce qui m'interpelle quand j'observe le marché suisse, c'est que la question de la dépendance arrive presque toujours après coup. Le dirigeant cherche d'abord à résoudre un problème opérationnel, ce qui est parfaitement logique. Mais le choix de la structure, de la documentation, de la propriété intellectuelle des workflows se fait dans les premières semaines du projet. Après, c'est du rattrapage. Et le rattrapage coûte trois fois plus cher que la prévention.
L'OFS relevait en 2022 que 65% des entreprises suisses utilisaient au moins une solution cloud, donc une forme de dépendance externe pour leur infrastructure numérique. Le cloud en soi n'est pas le problème. Le problème, c'est quand la couche d'automatisation qui tourne dessus n'est documentée nulle part et que les identifiants appartiennent à quelqu'un d'autre.
Première question. Qui possède quoi si tout s'arrête demain ?
Avant même de parler technique, il y a un test simple. Imagine que ton prestataire t'envoie un mail demain matin pour t'annoncer qu'il arrête son activité. Qu'est-ce qui continue de fonctionner sans intervention humaine ? Qu'est-ce qui s'arrête net ? Et surtout, qu'est-ce que tu ne sais même pas identifier ?
La propriété se joue sur trois niveaux distincts. Premier niveau, les comptes et accès. Les outils d'automatisation (Make, Zapier, n8n, Power Automate) tournent sur des comptes. Ces comptes sont-ils au nom de ton entreprise ou au nom du prestataire ? Si c'est le second cas, tu n'as techniquement rien. Deuxième niveau, la logique des workflows. Même si le compte t'appartient, est-ce que quelqu'un chez toi comprend ce que fait chaque scénario ? Troisième niveau, les données. Où transitent-elles, où sont-elles stockées, et dans quel format peux-tu les exporter ?
Ce n'est pas une question de méfiance envers un prestataire en particulier. C'est une question de structure. Un bon prestataire acceptera sans broncher que tu poses ces questions dès le départ. Si la réponse est floue ou si on te dit « on verra ça plus tard », c'est un signal. Pas forcément un signal de mauvaise foi, parfois juste un signal de désorganisation. Mais le résultat pour toi est le même.
Deuxième question. Quel est ton seuil de tolérance financière ?
Fais un calcul rapide. Prends le montant mensuel que tu paies à ton prestataire pour maintenir tes automatisations. Multiplie par 1.5. Est-ce que ce montant reste acceptable pour ton activité ? Si oui, tu as une marge. Si une augmentation de 50% te met en difficulté, alors ta dépendance est déjà un risque financier réel.
Maintenant un deuxième calcul. Estime le nombre d'heures par semaine que tes automatisations te font gagner. Multiplie par le coût horaire moyen de la personne qui ferait ce travail manuellement. Multiplie par 4 pour avoir le gain mensuel. Compare ce chiffre au coût mensuel du prestataire. Si le ratio est inférieur à 3 pour 1, tu paies cher pour ce que tu obtiens et ta marge de négociation en cas d'augmentation est faible.
Ces deux calculs ne donnent pas une réponse définitive. Ils donnent un cadre. Si tu découvres que ton ratio est de 8 pour 1, la dépendance existe mais elle est économiquement supportable même en cas de hausse de prix. Si ton ratio est de 2 pour 1, chaque augmentation grignote ton bénéfice réel. La question n'est pas « est-ce que je suis dépendant ? » mais « à quel point cette dépendance me coûterait-elle si les conditions changent ? ». J'ai détaillé la logique de mesure des coûts cachés dans l'article sur les KPI et coûts cachés des projets IA, qui complète bien cette réflexion.
Troisième question. Ta documentation survivrait-elle à un changement de prestataire ?
Voici un exercice que je trouve révélateur. Ouvre le dossier ou l'espace partagé qui concerne tes automatisations. Compte le nombre de documents qui décrivent ce que fait chaque workflow, pourquoi il a été construit ainsi, et comment le modifier. Si la réponse est zéro, tu es dans la situation la plus courante. Et la plus fragile.
La documentation n'est pas un luxe administratif. C'est ton assurance réversibilité. Sans elle, un nouveau prestataire devra passer des dizaines d'heures à comprendre ce qui existe avant de pouvoir intervenir. Ces heures, c'est toi qui les paies. Avec une documentation à jour, la transition devient un projet de quelques jours au lieu de quelques semaines.
Ce qui me frappe, c'est que beaucoup de prestataires ne documentent pas spontanément. Non par volonté de te garder captif, mais parce que documenter prend du temps et que personne ne le demande explicitement. C'est donc à toi de l'exiger dès le brief initial. Le template de brief pour consultant en automatisation que j'ai publié inclut d'ailleurs cette exigence comme clause standard. Si tu ne demandes pas la documentation dès le départ, tu ne l'auras probablement jamais.
Un bon minimum. Pour chaque automatisation, un document d'une page qui décrit l'objectif métier, les outils utilisés, les déclencheurs, les actions, et les accès nécessaires. Rien de plus complexe que ça.
Quatrième question. Quelle compétence interne te manque vraiment ?
Il y a une idée reçue tenace. Pour être autonome face à un prestataire d'automatisation, il faudrait devenir soi-même expert technique. C'est faux. Tu n'as pas besoin de savoir construire un workflow de zéro. Tu as besoin de savoir lire ce qu'il fait, identifier quand il dysfonctionne, et comprendre à quel endroit intervenir ou faire intervenir quelqu'un.
La compétence qui protège de la dépendance n'est pas technique au sens développeur. C'est une compétence de supervision. Savoir poser les bonnes questions. Savoir vérifier qu'un workflow produit le résultat attendu. Savoir où regarder quand quelque chose ne tourne plus rond. Dans une entreprise de 10 à 50 personnes, cette compétence peut tenir dans une seule personne, à condition qu'elle ait reçu un transfert structuré.
Le transfert de compétences, c'est le point qui manque le plus souvent dans les projets d'automatisation. Le prestataire livre, ça marche, tout le monde est content. Personne ne prend le temps de montrer à quelqu'un en interne comment ça fonctionne sous le capot. Six mois plus tard, quand un scénario plante un samedi soir, personne ne sait quoi faire. Le prestataire est en vacances. Et toi, tu es bloqué.
La question à poser avant de signer. « Combien d'heures de transfert de compétences sont incluses dans votre offre, et à qui seront-elles destinées ? » Si la réponse est « on fera ça à la fin du projet », méfie-toi. À la fin du projet, personne n'a le temps.
Un cadre pour décider avant de s'engager, pas après
Récapitulons les seuils de décision. Pas comme une checklist à cocher mécaniquement, mais comme un cadre pour savoir où tu en es et ce que tu acceptes consciemment.
- Les comptes et accès sont au nom de ton entreprise, oui ou non
- Une documentation exploitable par un tiers existe pour chaque automatisation
- Au moins une personne en interne peut superviser le fonctionnement courant
- Ton ratio gain/coût reste supérieur à 3 même en cas d'augmentation de 50%
- Tu peux exporter tes données dans un format standard sans intervention du prestataire
- Le contrat prévoit une clause de réversibilité avec délai et livrables définis
Si tu coches moins de trois points sur six, ta dépendance est structurelle. Ça ne veut pas dire que tu dois tout changer demain. Ça veut dire que tu prends un risque calculable, et que ce risque mérite d'être adressé dans les prochains mois plutôt que le jour où le problème explose.
Ce cadre n'est pas un outil pour éliminer tout prestataire externe. Travailler avec un partenaire compétent reste souvent la meilleure option pour une entreprise de ta taille. L'objectif est de collaborer depuis une position de choix, pas depuis une position de nécessité. La différence entre les deux se joue dans les premières semaines du projet. Si tu veux voir comment on structure cette autonomie dès le départ chez TimeKraft, la page services détaille notre approche de la réversibilité. Mais quel que soit le prestataire que tu choisis, ces six points restent valables.
