L’ingénierie logicielle regorge de lois officielles — comme celles de Hyrum, Conway ou Zawinski — qui structurent les bonnes pratiques. Mais au-delà de ces principes connus, il existe des règles non écrites, apprises à la dure par les développeurs après des erreurs coûteuses. L’article « The Unwritten Laws of Software Engineering » en dresse sept, illustrées par des anecdotes édifiantes. En voici une synthèse, accessible à tous, avec une touche d’humour et de sagesse terrain.
1. Tout est toujours lié : rollback d’abord, debug après
Combien de fois un déploiement a-t-il cassé la production, pour que le premier réflexe soit de nier toute responsabilité ? « Ce n’est pas lié à mon code ! » Pourtant, la réalité est implacable : si quelque chose cloche après un déploiement, c’est probablement lié. La leçon ? Ne perdez pas de temps à prouver votre innocence. Rollback immédiat, stabilisez le système, puis enquêtez. Une règle d’or pour éviter les heures de panique inutiles.
2. Les sauvegardes n’existent que si vous les avez restaurées
Avoir des sauvegardes, c’est bien. Savoir les restaurer, c’est mieux. Combien d’équipes découvrent, lors d’un incident, que leurs backups sont incomplets, corrompus, ou que personne ne connaît la procédure ? Pire : que les permissions manquent, ou que le temps de restauration est sous-estimé. « Une sauvegarde non testée est une sauvegarde inexistante », résume l’article. Et ce n’est pas un exercice ponctuel : les infrastructures évoluent, les données grossissent… Testez régulièrement.
3. Les logs : un éternel regret
« Je hais la façon dont j’ai écrit mes logs. » Qui n’a jamais maudit ses propres traces, trop vagues, trop verboses, ou mal structurées ? L’équilibre est délicat : il faut assez d’informations pour diagnostiquer, mais assez de clarté pour ne pas se noyer dans le bruit. Et avec l’essor des outils comme Cursor ou Claude, qui génèrent des logs ultra-détaillés, le problème se déplace… mais persiste.
4. Toujours prévoir un plan de rollback. TOUJOURS.
Même pour une migration mineure ou une modification de base de données anodine : si vous touchez aux données, prévoyez un rollback testé. Ajouter une colonne ? Préparez la migration inverse. Supprimer des données ? Sauvegardez-les d’abord. « Un plan de rollback non testé a 50 % de chances d’échouer », rappelle l’auteur. Une vérité crue, mais salvatrice.
5. Toute dépendance externe échouera (un jour)
Les API tierces sont des bombes à retardement. Un jour, elles dépasseront leurs limites de taux, planteront, ou changeront leur contrat sans préavis. « Une dépendance critique avec un SLA de 99,9 % double votre temps d’indisponibilité », calcule l’article. Les questions à se poser :
- Que se passe-t-il si l’API tombe ? Le feature est-elle dégradée, ou toute l’application ?
- Avez-vous testé en production le comportement de votre système sans cette dépendance ?
- Existe-t-il des mécanismes de fallback (cache, files d’attente, données obsolètes) ?
6. La règle des "4 yeux" : jamais seul face au doute
L’auteur avoue avoir détruit la base de données de son entreprise à cause d’une erreur stupide. La solution ? Ne jamais agir seul en cas de doute. « Quatre yeux valent mieux que deux », et souvent, le simple fait d’expliquer son action à voix haute révèle l’erreur. « Si c’est tard le soir ou le week-end et que vous ne voulez déranger personne… c’est le signe que vous ne devriez pas faire cette manipulation. »
7. Rien n’est plus permanent qu’une solution temporaire
« On réglera ça plus tard. » Traduction : « On ne le réglera jamais. » Les priorités changent, les nouveaux projets brillent plus que la maintenance. Résultat : les solutions quick and dirty deviennent des dettes techniques éternelles. La morale ? Même un MVP doit être propre. « Il y a une différence entre ‘simple et limité’ et ‘tenu par du ruban adhésif’ ».
Ces lois non écrites sont des cicatrices collectives de l’industrie. Elles rappellent que l’ingénierie logicielle n’est pas qu’une question de code, mais aussi de prudence, de préparation et d’humilité. Comme le dit l’article : "Tout le monde pense pouvoir construire du bon logiciel. Jusqu’à ce qu’il doive le maintenir."
Et vous ? Vous en pensez quoi ?