Ce qui casse quand on saute cette étape
Vous l’avez peut-être déjà vécu :
Architecture web
Les problèmes qui coûtent le plus cher ne viennent pas du code
ils viennent des décisions prises avant le développement.
Un site lent, ingérable, impossible à faire évoluer ou qu’il faut refaire au bout de deux ans : presque toujours, la cause remonte à une structure qui n’a jamais été pensée. C’est ce travail-là, invisible mais déterminant, que j’appelle l’architecture web.
- Un site devenu ingérable, où la moindre modification est une corvée.
- Un site lent, qu’on n’arrive pas vraiment à accélérer.
- Un projet dont les coûts explosent à chaque nouvelle demande.
- Un site qu’il faut refaire entièrement au bout de deux ans, faute de pouvoir le faire évoluer.
Ce ne sont pas des problèmes différents. C’est le même, sous quatre formes : un système construit sans architecture.
Une maison sans plan
Personne ne construirait une maison sans plan. On ne se contente pas d’empiler des briques en espérant que ça tienne : on pense d’abord les fondations, la structure, les circulations, et la façon dont la maison pourra s’agrandir.
Un site, un outil, une application, c’est pareil. L’architecture, ce sont les fondations qu’on ne voit pas une fois la construction terminée – mais qui décident si l’ensemble tiendra, restera modifiable, et pourra grandir. Bâtir sans elle, c’est élever un château de cartes : ça tient un temps, puis le moindre changement le fait vaciller.
En quoi consiste ce travail
Concevoir l’architecture d’un projet web, c’est réfléchir avant de construire. Concrètement :
-
Comprendre le besoin réel
Pas seulement ce qui est demandé, mais ce que l’activité exige vraiment.
-
Modéliser les données et leurs relations
Quelles informations, comment elles s’articulent, où elles vivent.
-
Anticiper les usages futurs
Ce que le projet devra absorber dans un an, dans trois ans.
-
Choisir la bonne structure et les bons outils
En fonction de tout cela – et non l’inverse.
C’est cette étape qui décide de tout le reste. Elle ne produit pas d’écran, pas de fonctionnalité visible – et c’est précisément pour ça qu’on la néglige.
À quoi ressemble une bonne architecture, concrètement ?
Prenons un exemple simple. Une entreprise propose des formations. Sans architecture, les informations sont recopiées partout : sur la page catalogue, sur chaque page de formation, dans les formulaires, dans les newsletters. Changer une date ou un tarif devient une corvée – et un risque d’erreur à chaque endroit oublié.
Avec une architecture pensée dès le départ, une formation n’existe qu’à un seul endroit. Le site, les formulaires, les listes et les exports puisent tous dans la même source d’information. Une modification prend quelques secondes et se répercute partout, automatiquement.
Le visiteur ne voit pas cette différence. L’équipe, elle, la ressent tous les jours. C’est exactement ce type de structure que je conçois : des systèmes qui restent simples à faire évoluer, même plusieurs années après leur mise en ligne.
Pourquoi presque personne ne le fait
Parce que l’architecture est invisible. On ne la voit pas dans une maquette, elle ne fait pas de jolie capture d’écran, et elle ne se vend pas aussi facilement qu’un design. Alors on va vite : on code, on livre, on encaisse. Le problème n’apparaît que plus tard – quand il faut faire évoluer le système, et qu’on découvre qu’il n’a pas été pensé pour ça.
À ce moment-là, il est trop tard : une erreur d’architecture ne se corrige pas avec quelques lignes de code. Elle se paie pendant des années.
Ce que ça change
Un projet bien architecturé ne se remarque pas – et c’est tout l’intérêt. Il fait ce qu’on attend de lui, sans drame :
-
Il évolue facilement
Ajouter une fonctionnalité prend des jours, pas des mois.
-
Il dure
Pas besoin de tout refaire au moindre changement de cap.
-
Il coûte moins cher à faire vivre
Parce qu’il n’accumule pas de dette.
-
Il reste maîtrisable
Par vous comme par le prochain qui interviendra dessus.
C’est la différence entre un site qu’on subit et un système qu’on pilote.
La preuve
Ce n’est pas une théorie : c’est exactement la façon dont je travaille sur tous mes projets. Sur la plateforme Reborneo, une fonctionnalité majeure a pu être ajoutée en une journée – là où, sans modélisation préalable, elle aurait demandé des mois. Pour le système d’information de la Maison de l’Emploi des Comores, tout a commencé par la modélisation des relations entre des dizaines d’acteurs, parce qu’à cette échelle, une erreur de structure se paierait pendant des années. Et le portail juridique du Ministère de la Justice des Comores n’a tenu ses exigences de conformité et de pérennité que parce qu’il a été structuré avant d’être codé.
Dans chaque cas, la technologie n’était qu’un moyen. C’est l’architecture qui a fait la différence.
Un projet à concevoir sur de bonnes fondations ?
Que vous lanciez un nouveau site, une application ou un système plus complexe, le meilleur investissement n’est pas dans le code : il est dans la réflexion qui le précède.
D’ailleurs, mon intervention s’arrête parfois avant même le développement : après le cadrage et la conception, il arrive qu’un client fasse réaliser le projet par son équipe interne ou par un autre prestataire. Et c’est très bien ainsi – à ce stade, mon travail a déjà produit l’essentiel de sa valeur : le projet repose sur des fondations solides.
Le code se remplace. Une architecture, beaucoup plus difficilement. C’est pour ça que je considère le cadrage et la conception comme les étapes les plus importantes d’un projet : quand elles sont solides, tout le reste devient simple.