La passation commence le premier jour

On imagine la passation comme une cérémonie de fin de projet : quelques réunions, un document de cent pages écrit dans l’urgence, une archive de dépôts. Puis l’équipe suivante découvre que le document décrit un système qui n’existe plus, que la CI est rouge depuis quatre mois et que personne ne sait où vit le certificat qui expire mardi.

Une passation qui réussit n’est pas un événement, c’est une propriété du projet, entretenue depuis le premier jour. La question directrice est simple : si l’équipe changeait demain, que faudrait-il avoir écrit aujourd’hui ? Tout ce qui suit découle de cette question.

Ce qui se transmet réellement

Un logiciel ne se résume pas à son code source. Ce qui se transmet, c’est la capacité à l’opérer, et elle tient en cinq inventaires :

le runbook : comment déployer, restaurer, diagnostiquer les pannes connues, avec les commandes exactes ;
la carte des accès : environnements, services tiers, DNS, certificats, et les secrets associés, rangés dans un coffre plutôt que dans la mémoire d’une personne ;
les décisions : un journal de décisions d’architecture courtes et datées, qui explique les pourquoi que le code ne dit pas ;
la dette assumée : la liste honnête de ce qui est fragile, contourné ou temporaire, car la dette cachée est celle qui coûte ;
le calendrier : expirations de certificats et de domaines, échéances de support des versions majeures, renouvellements de licences.

Si l’un de ces inventaires n’existe pas, la passation le découvrira au pire moment.

L’environnement reproductible est le socle

Toute la documentation du monde ne remplace pas un environnement qui se reconstruit en une commande. Infrastructure décrite en code, versions verrouillées par des lockfiles commités, données de développement générées ou anonymisées, et une CI qui reste verte : la CI verte est le véritable contrat de passation, la preuve exécutable que le système est celui qu’on décrit.

Le test le plus honnête coûte une demi-journée : faire installer le projet par quelqu’un qui n’y a jamais touché, en suivant uniquement le README. Chaque question posée est un trou dans la passation, et chaque trou comblé profite immédiatement à l’équipe en place.

La maintenance est une cadence, pas une réaction

La maintenance échoue quand elle n’existe que sous forme de réaction : une faille médiatisée, une panne, une montée de version forcée. Elle réussit quand elle a un rythme, et le rythme tient en trois niveaux :

Les outils d’automatisation (Renovate, Dependabot) ouvrent les propositions ; la CI décide ; l’équipe arbitre. Une mise à jour mineure qui attend six mois devient une mise à jour majeure de fait : les petites marches franchies souvent battent toujours la grande marche subie.

Deux règles rendent la cadence tenable. D’abord, un budget : une fenêtre récurrente réservée dans le planning, non négociable, car la maintenance qui dépend du « temps qu’il reste » n’existe pas. Ensuite, une politique de versions explicite : quelles briques suivent la dernière version, lesquelles suivent la version de support long terme, et jusqu’à quand.

Semver est une convention, pas une promesse

Le versionnage sémantique dit l’intention de l’auteur, pas la réalité de votre système. Une mineure peut casser un comportement dont vous dépendiez sans le savoir. La confiance vient d’ailleurs : des tests qui couvrent les usages réels du projet, un changelog lu avant la montée de version, et des mises à jour par petits lots, isolées, faciles à annuler. C’est aussi pour cela que les mises à jour groupées mensuelles fonctionnent : un lot raisonnable, testé ensemble, annulable ensemble.

Mesurer la santé, pas seulement l’activité

Un logiciel transmis doit emporter ses instruments de bord : quelques indicateurs de disponibilité et d’erreur qui alertent des humains, la liste des dépendances en fin de vie, l’âge moyen du retard de mise à jour. Peu d’indicateurs, mais regardés. Un tableau de bord que personne n’ouvre est un artefact de réunion, pas un instrument.

Le test final : donner les clés à blanc

La meilleure vérification d’une passation se fait avant qu’elle ne soit nécessaire : un exercice où un membre extérieur au projet prend un incident simulé, du diagnostic au correctif déployé, en n’utilisant que ce qui est documenté. L’exercice coûte une journée et rapporte la seule information qui compte : le système survivrait-il au départ de ses auteurs ?

La checklist que nous appliquons

Runbook opérable : déployer, restaurer, diagnostiquer, avec les commandes.
Accès et secrets inventoriés dans un coffre, jamais dans une tête.
Journal des décisions d’architecture tenu au fil de l’eau.
Dette et contournements documentés sans complaisance.
Environnement reconstruisible en une commande, CI verte exigée.
Cadence de maintenance : sécurité en jours, mineures en mensuel, majeures planifiées.
Automatisation des propositions de mise à jour, arbitrage humain.
Calendrier des expirations : certificats, domaines, fins de support.
Exercice de passation à blanc une fois par an.

Un logiciel bien transmis n’est pas un logiciel parfait. C’est un logiciel dont la prochaine équipe peut dire, au bout d’une semaine : « on sait où on met les pieds ».