30 June 20267 min de lecture
Toute mission prend fin. Certaines parce que le travail est terminé, d’autres parce que la compétence est réinternalisée, d’autres parce qu’elle a cessé de fonctionner, et quelques-unes parce que la personne que vous appréciiez a pris un autre poste. La raison varie. La fin, non.
Malgré cela, la passation est presque toujours improvisée dans la dernière quinzaine, par des personnes déjà parties mentalement, sous contrainte d’échéance, sans budget dédié. Le résultat est un dossier de documents qui répondent à des questions que personne n’allait poser et omettent les trois points qui comptaient vraiment.
La passation commence le premier jour
Les équipes qui transmettent bien n’ont pas une meilleure dernière quinzaine. Elles ont eu un premier mois différent. Elles ont organisé la mission pour que la connaissance ne soit jamais uniquement dans la tête de quelqu’un, si bien que la passation consiste surtout à pointer des choses qui existent déjà.
La version pratique : les décisions sont écrites là où vit le travail, les notes d’architecture se trouvent à côté du code qu’elles décrivent, et aucun service, compte ou chemin de déploiement n’est compris par exactement une personne. Rien de tout cela n’est du travail de passation. C’est une pratique ordinaire qui a pour effet de rendre la passation quasiment gratuite.
C’est aussi l’argument pour exiger dès le départ que le dépôt, les comptes cloud, le nom de domaine et la configuration de la CI soient les vôtres, le partenaire travaillant à l’intérieur. Cela ressemble à une question de confiance. Ce n’en est pas une. C’est la différence entre une passation et une migration.
Ce qui doit réellement être transmis
Pas le code. Le code se transmet tout seul ; il est dans le dépôt et il dit ce qu’il fait. Ce qui ne se transmet pas, c’est tout ce qui l’explique.
- Pourquoi le système a la forme qu’il a, y compris les contraintes qui n’existent plus mais expliquent encore la conception.
- Les modes de défaillance : ce qui casse, comment le repérer, et quel est généralement le remède.
- La connaissance opérationnelle : comment déployer, comment revenir en arrière, que faire quand le traitement nocturne échoue, quelle alerte peut être ignorée et laquelle ne le peut pas.
- Les relations et dépendances extérieures au code : quel tiers n’est pas fiable, de qui il faut l’accord pour un changement de schéma, quel client ne peut pas tolérer une interruption un lundi.
- Les chantiers en suspens : ce qui a été délibérément laissé de côté, ce qui a été laissé faute de temps, et ce dont on sait que c’est faux sans que cela vaille encore la peine d’être corrigé.
Cette dernière catégorie est celle qu’on omet, parce que l’écrire ressemble à un aveu. C’est la page la plus précieuse de toute la passation.
Une documentation écrite par la mauvaise personne ne sert à rien
La personne qui a construit un système ne voit pas ce qui y est déroutant. Demandez-lui de le documenter et vous obtiendrez une description exacte qui ne répond à aucune des questions d’un nouveau venu, parce que ces questions ne lui sont jamais venues à l’esprit.
Un meilleur mécanisme : faire écrire la documentation par la personne qui reprend le poste, en parcourant le système et en posant des questions, la personne sur le départ corrigeant plutôt que rédigeant. C’est plus lent, cela paraît inefficace, et cela produit une documentation destinée au bon lecteur, ainsi qu’un repreneur qui s’est réellement impliqué au lieu de classer un document.
La période de chevauchement est tout l’enjeu
La passation par document ne suffit pas. Ce qui fonctionne, c’est une période, de deux à quatre semaines pour un système de taille ordinaire, où les deux personnes sont payées et où l’arrivant fait le travail pendant que le partant reste disponible pour répondre.
La séquence qui fonctionne : celui qui reprend traite de vrais tickets, pas des exercices, en commençant par quelque chose de petit et en finissant par quelque chose qui touche la partie effrayante du système. La personne sur le départ est joignable pour les questions et relit le travail, mais ne le fait pas. Si un incident de production survient pendant cette période, c’est le repreneur qui le traite, l’autre personne observant. Rien d’autre ne produit la même confiance.
Cette période coûte de l’argent réel, puisque vous payez deux fois la même couverture. Elle reste bien moins chère que l’alternative, et c’est la ligne le plus souvent supprimée d’un budget de transition par quelqu’un qui n’a jamais vécu une mauvaise passation.
Les parties ennuyeuses, réglées tôt
Les accès, la propriété et la paperasse ne sont pas passionnants, et c’est là que les passations se bloquent réellement. Vérifiez que la cession de propriété intellectuelle couvre tout ce qui a été livré, y compris le travail de tout sous-traitant, que l’accord de sous-traitance des données est clôturé correctement et les données personnelles supprimées là où elles doivent l’être, et qu’aucun compte de production, certificat, domaine ou intégration tierce n’est enregistré au nom d’une personne qui s’en va.
Le compte enregistré à l’adresse e-mail personnelle de quelqu’un est le cas classique. On le découvre onze mois plus tard, quand le certificat expire un dimanche et que la seule personne capable de le renouveler ne travaille plus avec vous depuis le printemps.
La passation comme habitude, pas comme événement
La protection la plus fiable consiste à rendre les petites passations routinières quand rien ne se termine. Faites tourner tous les quelques mois la responsabilité de chaque domaine. Faites présenter de temps à autre un système par quelqu’un d’autre que son auteur, en séance d’équipe. Traitez tout composant compris par exactement une personne comme un risque à inscrire sur une liste, et non comme une fatalité.
Une équipe qui procède ainsi a déjà répété le transfert une douzaine de fois avant qu’il ne compte. Une équipe qui ne le fait pas mise sur une quinzaine de jours à la fin, organisée par des gens qui pensent déjà à autre chose : exactement l’arrangement qu’il vaut la peine de consacrer un paragraphe de l’énoncé des travaux à éviter.