Passation sans lock-in: pour qu'une autre équipe puisse continuer

"Que se passe-t-il quand vous n'êtes plus là?" C'est l'une des questions les plus honnêtes qu'un client puisse poser - et la réponse ne doit pas être "on reste, voilà". Une base de code qu'une autre équipe peut reprendre est déjà la base de code la plus robuste, dès le premier jour.

À quoi ressemble le lock-in vu de près

Le lock-in est rarement un contrat unique qui vous lie pour dix ans. Le lock-in quotidien est fait de petites choses qui ensemble rendent un changement coûteux:

• Configuration non documentée. Un fichier env avec 40 variables, dont la moitié seulement est expliquée quelque part.
• Déploiements à moitié automatisés. Un script qui ne fonctionne que sur un laptop, parce qu'un outil y a été installé il y a deux ans.
• Conventions implicites. "On nomme toujours les branches comme ça" - mais aucun README ne dit pourquoi.
• Outils maison pour des problèmes standard. Un logger propre, un client HTTP propre, une bibliothèque CSV propre.

Chaque élément est petit. Ensemble, ils transforment une passation en un projet de plusieurs semaines.

Quatre piliers d'une base de code prête à la passation

Quatre choses ont le plus grand effet - et sont réalistes dans tout projet.

1. Un script d'onboarding qui tourne vraiment. ./scripts/setup.sh depuis un laptop vide, et après dix minutes l'application tourne en local. Si le script ne va pas au bout, c'est un bug, pas un détail de confort.
2. Architecture Decision Records. Un fichier par décision pertinente avec contexte, alternatives considérées, justification. Pas de long wiki - 200 lignes par ADR suffisent. Ils répondent aux questions qu'une nouvelle équipe pose dans les premières semaines.
3. Stack standard avant fait maison. Avant toute solution custom, la question: existe-t-il une brique OSS répandue qui suffit? Le fait maison est souvent élégant et hostile à la passation.
4. Pipeline CI lisible. Si la pipeline est en trois phases claires (build, test, deploy), une nouvelle équipe peut la modifier à la première lecture. Si ce sont 14 workflows Forgejo qui s'appellent entre eux, non.

Pourquoi ce n'est pas décoratif

Ces piliers ne sont pas de la "maintenance de doc". C'est de la discipline d'ingénierie qui paie directement dans le travail courant:

• Les scripts d'onboarding évitent que l'équipe actuelle trébuche elle-même - chaque nouveau laptop, chaque rebuild de container en profite.
• Les ADR évitent les discussions qui recommencent tous les trois mois - "pourquoi on utilise X déjà?".
• Le stack standard réduit le code que l'équipe doit maintenir elle-même - chaque ligne custom est de la dette de maintenance.
• Les pipelines lisibles raccourcissent l'analyse d'erreur - les builds cassés ne sont pas un mystère.

Autrement dit: l'investissement paie même si la passation n'a jamais lieu.

Le test terrain de deux semaines

Un test honnête dure deux semaines: une personne qui ne connaît pas le projet reçoit le dépôt, le README, rien d'autre. Elle doit livrer une fonctionnalité non triviale. Les endroits où elle doit poser des questions sont les trous de votre matériel d'onboarding.

Nous le faisons nous-mêmes régulièrement - et trouvons deux ou trois trous non évidents à chaque fois. C'est exactement le but: sans test, pas de garantie; avec test, une liste.

Le signal de confiance vers l'extérieur

Les clients qui ont déjà été coincés dans un lock-in flairent vite le contraire. "Nous livrons une documentation de passation qui permet à une autre équipe de reprendre en deux semaines" est une promesse concrète qu'on tient ou non. C'est un signal de confiance bien plus crédible que n'importe quelle certification.