← Retour au blog

Ça commence toujours de la même façon : un prestataire compétent, une relation de confiance, des livraisons qui tiennent. Puis, progressivement, il devient le seul à comprendre votre architecture. Le seul à avoir les accès. Le seul à pouvoir estimer une évolution. Et un jour, vous réalisez que vous ne pouvez plus rien décider sans lui — et que lui le sait. Ce n'est pas une situation exceptionnelle. C'est le schéma le plus courant dans les PME qui n'ont pas de direction technique interne. Voici comment en sortir.

Les 6 signaux que vous êtes en situation de lock-in

Ces signaux ne sont pas toujours intentionnels de la part du prestataire. Parfois, c'est simplement le résultat d'une relation qui s'est installée sans gouvernance claire. Mais le résultat est le même.

🔑
Vous n'avez pas accès à vos propres environnements

Serveurs, dépôts de code, bases de données, comptes cloud — les accès admin sont chez lui. Si demain il ne répond plus, vous ne pouvez pas entrer dans votre propre système. C'est le signe de lock-in le plus grave et le plus courant.

📋
Il n'y a aucune documentation de ce qui a été construit

Pas de README, pas de schéma d'architecture, pas de guide de déploiement. La connaissance de votre système n'existe que dans la tête de votre prestataire. Faire entrer quelqu'un d'autre demande des semaines de reverse engineering — et c'est lui qui fixe le prix de ce transfert.

💰
Ses tarifs ont augmenté et vous ne pouvez pas aller voir ailleurs

Vous avez accepté une hausse de TJM parce que le coût de transition vous semblait plus élevé que la hausse elle-même. C'est exactement la définition d'une rente de situation. Il l'a peut-être calculé — ou pas. Peu importe : le résultat est identique.

🚧
Faire intervenir quelqu'un d'autre crée des frictions

Quand vous avez essayé de faire auditer son travail ou d'introduire un autre prestataire, il a rendu ça difficile : manque de disponibilité pour le briefing, documentation soudainement introuvable, discours sur la "complexité" du système. Un prestataire sûr de son travail accueille le regard externe.

⏱️
Chaque demande d'évolution arrive avec une estimation surprenante

Une fonctionnalité qui "devrait prendre 3 jours" selon votre instinct vous est facturée 15 jours. Sans interlocuteur technique indépendant pour challenger ces estimations, vous signez à l'aveugle — et il le sait.

📞
Vous n'êtes jamais sûr de sa disponibilité en cas de crise

Bug en production à 23h, incident sur un client important — vous espérez qu'il répond. Pas parce qu'il y est contractuellement obligé, mais parce qu'il est le seul à pouvoir corriger. Ce "j'espère qu'il répond" résume toute la fragilité de la situation.

Ce que le lock-in vous coûte vraiment

Le coût apparent, c'est le TJM que vous payez. Le coût réel est ailleurs — et il s'aggrave avec le temps.

Le coût de l'opacité : vous prenez des décisions business (lancer une fonctionnalité, changer de marché, intégrer un partenaire) sans savoir si votre infrastructure peut les supporter. Chaque décision est un pari.

Le coût de la sur-facturation silencieuse : sans comparaison possible, vous n'avez aucun moyen de savoir si vous payez le prix du marché ou une prime de dépendance. Les études sectorielles montrent des écarts de 40 à 80% sur les estimations entre un prestataire en situation de lock-in et un prestataire challengé.

Le coût du risque opérationnel : une indisponibilité, un conflit, un départ de votre prestataire — et votre activité s'arrête. C'est une vulnérabilité que vous ne pouvez pas vous permettre de maintenir indéfiniment.

La question n'est pas "est-ce que mon prestataire est de mauvaise foi ?" La question est "est-ce que je pourrais continuer à fonctionner si cette relation s'arrêtait demain ?" Si la réponse est non, vous avez un problème structurel indépendamment de la qualité humaine de votre prestataire.

La méthode en 3 phases pour reprendre la main

Sortir d'une dépendance prestataire ne se fait pas en une semaine et ne se fait pas par rupture brutale. Voici la séquence qui fonctionne.

01
Audit de la situation réelle

Avant d'agir, comprendre précisément ce qui est en jeu. Cette phase dure 5 à 10 jours et produit un état des lieux factuel.

Cartographie des accès : qui a accès à quoi ? Environnements, dépôts, DNS, comptes de paiement cloud, outils tiers.

Cartographie de la connaissance : qu'est-ce qui est documenté ? Qu'est-ce qui n'existe que dans la tête du prestataire ?

Évaluation des risques : que se passe-t-il concrètement si la relation s'arrête demain ? Quels systèmes tombent ? En combien de temps ?

Analyse des contrats : que disent les contrats sur la propriété du code, la restitution des accès, les délais de préavis ?

02
Récupération progressive des actifs critiques

Une fois la situation cartographiée, récupérer ce qui vous appartient — sans rupture de la relation de travail en cours.

Récupérer les accès en premier : demander les accès admin à tous vos environnements. C'est votre code, votre infrastructure, vos données. Ce n'est pas négociable et ça ne l'a jamais été.

Exiger la documentation comme livrable : intégrer dans les prochains jalons une exigence de documentation. Pas une documentation parfaite — une documentation suffisante pour qu'un autre prestataire puisse prendre la main.

Introduire un regard externe neutre : faire valider les prochaines estimations par un tiers technique. Cette étape rééquilibre la relation sans rupture.

03
Décision éclairée sur la suite de la relation

Une fois la visibilité retrouvée et les actifs récupérés, vous pouvez décider sereinement — continuer avec un cadre renforcé, ou transitionner vers un autre prestataire.

Si vous continuez : formaliser un contrat clair (propriété du code, SLA, accès garantis, documentation obligatoire), et maintenir un regard externe trimestriel pour éviter de retomber dans la même situation.

Si vous transitionnez : prévoir une période de chevauchement (4 à 8 semaines) où l'ancien et le nouveau prestataire coexistent. Ne jamais couper la relation avant que le nouveau soit autonome.

Ce que vous ne pouvez pas faire seul dans cette démarche

Les phases 1 et 3 (audit et décision) nécessitent un regard technique indépendant. Sans lui, deux risques concrets :

Vous ne voyez pas ce que vous ne savez pas chercher. La cartographie des risques d'une architecture demande de savoir lire ce qui est en place. Un fondateur non-technique peut poser les bonnes questions — il ne peut pas interpréter les réponses techniques seul.

Votre prestataire a une longueur d'avance dans la négociation. Il connaît la complexité réelle de son système. Vous, non. Sans tiers technique à vos côtés, chaque conversation sur les accès, la documentation ou la transition se fait à armes inégales.

C'est précisément le rôle d'un diagnostic technique : produire en 5 jours l'état des lieux factuel qui vous donne la visibilité pour décider et la légitimité pour exiger.