Livraison

Livrer un logiciel qui tient encore après la transmission

Mis à jour 24 juil. 2026 · 3 min de lecture

Beaucoup de logiciels fonctionnent le jour du lancement puis se dégradent en silence. Nous nous soucions plus de la deuxième année que de la première semaine, car c'est là que se trouve la vraie valeur d'un produit.

Levi à son bureau chez Punfyre, écrans et bibliothèque derrière lui
Levi au bureau Punfyre. Livrer est une relation, pas un moment de passation.

Penser la transmission dès le premier jour

Nous construisons en sachant que quelqu'un d'autre le fera tourner un jour, y compris votre propre équipe. Une structure claire, une documentation honnête, et aucune astuce qui n'a de sens que pour son auteur. Les tests automatisés font partie de la même promesse : ils permettent au développeur suivant de modifier avec confiance, au lieu d'avancer sur la pointe des pieds autour d'un code que personne n'ose toucher.

Itérer à ciel ouvert

Des cycles courts font que vous savez toujours où en sont les choses et pouvez corriger le cap tôt, tant que c'est peu coûteux. Pas de grande révélation à la fin, pas de surprises sur ce qui a été coupé, juste des progrès visibles et réguliers sur lesquels planifier.

Écrire comme si vous partiez

La documentation échoue quand elle veut tout décrire. Nous la limitons à ce dont la personne suivante a vraiment besoin : comment le faire tourner, comment déployer, où vivent les données, et les décisions qui seraient sinon rejugées dans un an. Un document court et vrai bat chaque fois un document long et périmé, et sa mise à jour fait partie de la fin d'un changement, pas d'une corvée séparée qui n'arrive jamais.

Ce qu'une transmission comprend vraiment

  • Accès et propriété : comptes, domaines, identifiants et facturation transférés chez vous, rien qui reste suspendu chez nous.
  • Un runbook pour le travail courant : déployer, sauvegarder, surveiller, et quoi faire quand une dépendance doit être mise à jour.
  • Le journal des décisions : pourquoi le système a cette forme, pour que le développeur suivant change en connaissance de cause et non par accident.
  • Les fins ouvertes, nommées : les raccourcis pris sciemment et ce que nous attaquerions ensuite.

Faire du dernier jour un jour tranquille

La livraison n'est pas le moment où nous partons. C'est le moment où le logiciel doit tenir seul : comptes transmis, accès transférés, et l'équipe qui en hérite assez confiante pour oser la modification suivante. Tout ce que nous faisons avant vise à rendre ce jour sans histoire. Ce qui vient après est une discipline discrète à part entière.