Comment ne pas être pris en otage par ses développeurs

La pire situation pour un fondateur non-tech : un beau matin, ton CTO démissionne, ton freelance disparaît, ou ton agence triple ses tarifs. Et tu réalises que personne d'autre ne peut toucher au code sans 3 mois de prise en main.

Cette dépendance n'est pas une fatalité. Elle est même évitable avec 5 décisions prises au bon moment — pas après.

On l'a vu une trentaine de fois en 8 ans, à chaque fois qu'on est appelés pour reprendre un produit existant : les fondateurs non-tech qui s'en sortent ont fait les mêmes choix tôt. Voici lesquels.

D'où vient la dépendance

Trois mécanismes différents, qui s'empilent souvent :

Le code n'est pas documenté. Pas de README, pas d'ADR, pas de schéma d'architecture. Le savoir vit dans la tête d'une seule personne. Le jour où elle part, plus personne ne sait pourquoi telle décision a été prise.

La connaissance fonctionnelle vit aussi dans la tête du dev. Ton dev a inventé des règles métier en cours de route, parce que tu ne les avais pas spécifiées. Maintenant ces règles sont dans le code, et personne ne sait ce qui est intentionnel ou ce qui est un bug.

L'infra est un château de cartes. Comptes Cloud personnels du dev, accès AWS au nom du freelance, mots de passe partagés via Slack DMs. Tu n'as même pas l'admin sur ton propre produit.

La fusion des trois te met en otage. Une seule absence et tout s'arrête.

Levier 1 — Posséder ton repo Git, ton infra, tes domaines

C'est le plus basique et c'est encore raté 1 fois sur 3. Vérifie maintenant :

• Le repo GitHub est sur ton organisation, pas celle du freelance ou de l'agence. Tu es admin.
• L'infra (Vercel, AWS, Supabase, Cloudflare) est sur ton compte, payée par ta carte.
• Les noms de domaine sont sur ton OVH/Gandi/Namecheap, pas chez le prestataire.
• Tu as les credentials root, ton dev a un compte secondaire.

Si l'une de ces lignes n'est pas vraie : règle ça cette semaine. C'est non négociable.

Levier 2 — Imposer un README + 3 docs minimum

Pas besoin d'une wiki Confluence avec 200 pages. Quatre fichiers à la racine du repo suffisent :

• README.md : comment lancer le projet en local en 5 commandes
• ARCHITECTURE.md : un schéma + 1 page de description (front, back, DB, services tiers)
• DEPLOY.md : comment déployer en prod, qui a les accès, où voir les logs
• DECISIONS.md : les choix techniques importants et pourquoi (« on utilise Postgres et pas Mongo parce que… »)

Ces 4 fichiers prennent 2 jours à écrire la première fois et permettent à n'importe quel dev compétent de reprendre le projet en une semaine au lieu de trois mois.

Mets-les en condition d'embauche dans le contrat freelance. Pas de docs, pas de paiement final.

Levier 3 — Pas plus de 60% de la connaissance dans une seule tête

Le bus factor à 1, c'est la définition de l'otage. Tu as deux moyens de monter à 2 :

Pair-programming systémique sur les briques critiques. Quand une feature touche au paiement, à l'auth, à la facturation : 2 devs en synchrone. Ça ralentit de 20%, ça blinde le bus factor.

Code review obligatoire. Pas une review 2 minutes pour le merge, une vraie review où le reviewer doit pouvoir expliquer la PR à voix haute. Si ton équipe est solo, embauche un dev senior 2h/semaine en mode tech advisor — 600 €/mois, ça change la vie.

Levier 4 — Spécifier les règles métier ailleurs que dans le code

Le moment dangereux : ton dev te dit « j'ai mis la règle ici » et toi tu dis « ok ». Six mois plus tard, personne ne se souvient de pourquoi le calcul de TVA fonctionne comme ça.

Solution : un fichier BUSINESS_RULES.md ou un Notion liée au repo, où toi (le fondateur) écris les règles métier en français. Le dev peut linker des sections du code vers ces règles. Si une règle change, c'est dans Notion d'abord, dans le code ensuite.

Tu reprends le contrôle de la définition fonctionnelle, ton dev exécute. C'est l'inverse de la situation où le dev devient de facto le product owner par défaut.

Levier 5 — Tester la transmissibilité 1 fois par an

Une fois par an, fais l'exercice : invite un dev externe à passer 4 heures sur ton repo, sans aide de ton équipe. Donne-lui le README, les 4 docs, les accès. Demande-lui de :

• Lancer le projet en local
• Identifier les 3 plus gros risques techniques
• Décrire l'archi à voix haute

Si en 4 heures il y arrive : ton bus factor est sain. Si non : tu sais ce que tu dois corriger. Coût : 800-1 200 €. Économie potentielle : ton produit le jour où ton dev part.

Ce qu'on fait chez Zetos

On structure tous nos projets pour qu'ils soient transmissibles dès le jour 1. Concrètement :

• Le code est sur ton repo GitHub, pas le nôtre
• Le contrat prévoit la cession totale des droits, pas une licence
• Les 4 docs (README, ARCHITECTURE, DEPLOY, DECISIONS) sont écrites et à jour à la livraison
• À la fin de chaque projet, on fait une session de transmission de 2-3 jours avec ton équipe ou ton futur prestataire
• On a déjà fait cette transition une dizaine de fois — exemples : CS Consulting (reprise interne après 18 mois) et Meeriad (transmission à leur équipe tech grossissante)

Notre conviction : un bon prestataire, c'est celui dont tu peux te passer si tu le décides. Pas celui qui te rend captif par défaut.

Bottom line

Si tu démarres un projet cette semaine :

1. Repo, infra, domaines à ton nom dès le commit 1
2. 4 fichiers docs en condition de paiement final
3. Code review obligatoire ou tech advisor à 2h/semaine

Si tu as déjà un produit en prod et que tu lis ça avec l'estomac serré, fais l'audit transmissibilité ce mois-ci. C'est 1 jour de boulot, ça te dit où tu es vulnérable.

Si tu veux qu'on regarde ton existant, on fait des audits techniques de 1 à 2 semaines avec rapport et roadmap chiffrés. À la fin, tu sais exactement quoi corriger pour reprendre la main.