Construire des Systèmes Durables : Leçons des Bâtisseurs Anciens

Le Panthéon de Rome est debout depuis près de 2 000 ans. Les logiciels modernes ne survivent souvent pas 2 ans sans réécritures majeures. Que peuvent nous enseigner les bâtisseurs anciens sur la création de systèmes durables ?

Le Principe de Fondation

“C’est pourquoi, quiconque entend ces paroles que je dis et les met en pratique, sera semblable à un homme prudent qui a bâti sa maison sur le roc.” - Matthieu 7:24 (LSG)

Les bâtisseurs romains anciens savaient : la fondation détermine la longévité. En logiciel :

Fondations faibles :

• Décisions d’architecture précipitées
• “Aller vite et casser des choses” sans réflexion
• Accumulation de dette technique
• Exigences peu claires

Fondations solides :

• Définition claire du problème
• Architecture bien réfléchie
• Décisions documentées
• Modèles de conception flexibles

Étude de Cas : La Méthode PARA

Lors de la construction de mon vault de connaissances personnel, j’aurais pu utiliser :

• Ad-hoc - Créer des dossiers au besoin (chaotique, ne s’échelonne pas)
• Taxonomie rigide - Hiérarchies détaillées (fragile, difficile à maintenir)
• Méthode PARA - Projets, Domaines, Ressources, Archives (flexible, éprouvée)

J’ai choisi PARA parce qu’elle est :

• Éprouvée - Utilisée avec succès par des milliers
• Flexible - S’adapte à différents contextes
• Simple - Quatre catégories, règles claires
• Durable - La structure reste stable à mesure que le contenu croît

Résultat : 277+ dépôts organisés, facile de tout trouver, système s’échelonne sans effort.

L’État d’Esprit “Construire Une Fois, Maintenir Toujours”

Le béton romain (opus caementicium) était conçu pour s’auto-guérir grâce à des réactions chimiques avec l’eau de mer. Le béton moderne s’effrite en quelques décennies.

Caractéristiques d’un logiciel auto-guérisseur :

• Documentation claire - Les futurs mainteneurs comprennent pourquoi
• Tests automatisés - Capturent les régressions immédiatement
• Design modulaire - Remplacer des pièces sans tout réécrire
• Journalisation & surveillance - Le système rapporte sa propre santé

Anti-Pattern : Le Piège de la “Réécriture”

“As-tu vu un homme habile dans son ouvrage ? Il se tiendra devant les rois” - Proverbes 22:29 (LSG)

Beaucoup de développeurs tombent dans le piège de la réécriture :

1. Héritent d’une base de code “legacy”
2. La déclarent impossible à maintenir
3. La réécrivent de zéro
4. Le nouveau système a les mêmes problèmes + de nouveaux
5. Répètent dans 2-3 ans

Meilleure approche :

1. Comprendre pourquoi le système actuel existe
2. Identifier les véritables points de douleur (pas juste “je l’aurais fait différemment”)
3. Refactoriser progressivement
4. Documenter les apprentissages
5. Construire sur ce qui fonctionne

Application Pratique : Le Pattern Strangler Fig

Nommé d’après les arbres qui remplacent progressivement leur hôte, le pattern strangler fig vous permet de reconstruire pendant que l’ancien système fonctionne :

# Phase 1 : L'ancien monolithe gère tout
def traiter_commande(commande):
    # 500 lignes de code legacy
    pass

# Phase 2 : Extraire une pièce, déléguer les autres
def traiter_commande_v2(commande):
    if doit_utiliser_nouveau_systeme(commande):
        return nouveau_service_commandes.traiter(commande)  # Nouveau système
    else:
        return traiter_commande(commande)  # Repli legacy

# Phase 3 : Étendre progressivement la couverture du nouveau système
# Phase 4 : Finalement supprimer le code legacy

Cette approche :

• ✅ Minimise le risque (repli vers legacy si nouveau système échoue)
• ✅ Livre de la valeur progressivement (améliorer pièce par pièce)
• ✅ Maintient la continuité de service (pas de coupure big-bang)

Sagesse pour le Long Terme

Proverbes 24:27 (LSG) :

“Soigne ton travail au dehors, mets ton champ en état, puis tu bâtiras ta maison.”

Leçons pour des systèmes durables :

1. Concevoir avant de construire - Le papier est moins cher que le code
2. Standards plutôt que nouveauté - La technologie ennuyeuse fonctionne
3. La documentation est une infrastructure - Le code explique comment, les docs expliquent pourquoi
4. Tester les hypothèses tôt - Valider avant d’investir
5. Planifier pour le changement - La seule constante est le changement

Conclusion

Le dôme du Panthéon reste le plus grand dôme en béton non armé au monde parce que ses constructeurs pensaient en siècles, pas en trimestres.

Quand vous écrivez du code aujourd’hui, demandez-vous :

• Quelqu’un comprendra-t-il ceci dans 5 ans ?
• Ceci peut-il s’adapter aux exigences changeantes ?
• Est-ce que je construis sur des fondations éprouvées ou je poursuis la nouveauté ?
• Serais-je fier de maintenir ceci moi-même dans 10 ans ?

Construisez pour le long terme. Construisez pour ceux qui viennent après vous. Construisez comme si vous construisiez une cathédrale, pas un campement.

Question de Réflexion : Quel est un morceau de code ou système que vous maintenez qui bénéficierait d’une meilleure documentation ou refactorisation pour la durabilité à long terme ?