Quand on m'a confié la co-conception d'un système industriel multi-sites couvrant la production, les ventes et la logistique, j'ai compris que quelque chose avait changé dans ma façon de travailler. Je ne pensais plus en termes de fonctionnalités à coder. Je pensais en termes de contraintes à absorber, de flux à modéliser et de décisions qui seraient impossibles à défaire six mois plus tard.
Ce n'est pas l'expérience seule qui crée cette transition. J'ai vu des développeurs de dix ans d'expérience penser encore comme des juniors sur les questions de conception. Et j'ai vu des développeurs de trois ans poser des questions d'architecture que des seniors n'avaient pas pensé à poser.
La différence n'est pas dans le nombre d'années. Elle est dans le niveau d'abstraction auquel on raisonne quand on est face à un problème.
Le développeur résout le problème posé. L'architecte questionne le problème.
Un client dit : "Je veux un bouton pour exporter les données en Excel." Un développeur ouvre son éditeur et commence à chercher une bibliothèque d'export. Un architecte demande : qui va utiliser cet export ? À quelle fréquence ? Quels volumes ? Est-ce que ce besoin va évoluer vers d'autres formats ? Est-ce que c'est vraiment un export qu'il faut, ou un rapport ?
Ces questions ne ralentissent pas le projet. Elles évitent de construire la mauvaise chose. Sur un projet de gestion d'opérations terrain pour une entreprise BTP, la première version du cahier des charges demandait un système de planification. Après deux heures de questions, il est apparu que le vrai besoin était un système de coordination en temps réel sur le terrain. Ce n'est pas la même architecture, pas les mêmes contraintes, pas les mêmes choix techniques.
Face à n'importe quelle demande fonctionnelle, demander "pourquoi ?" cinq fois de suite. Pas pour être difficile : l'objectif est d'atteindre la contrainte métier réelle qui se cache derrière la demande exprimée. La demande exprimée est rarement le vrai problème.
Le développeur pense à aujourd'hui. L'architecte pense à dans six mois.
Quand on code une fonctionnalité, la question naturelle est : est-ce que ça marche ? Quand on conçoit un système, la question devient : est-ce que ça va tenir quand les besoins vont changer ?
Parce que les besoins changent. Toujours. Sur un projet de plateforme d'échange communautaire avec monnaie virtuelle, la logique de transaction qui semblait simple au départ a dû évoluer pour gérer des cas que le client n'avait pas anticipés : transactions partielles, litiges, remboursements en monnaie virtuelle vs remboursements réels. Un système conçu sans aucune séparation entre la logique de transaction et la couche de présentation aurait nécessité une réécriture complète.
L'architecte ne prédit pas l'avenir. Il conçoit un système qui peut absorber des changements sans s'effondrer. Ce n'est pas la même chose que sur-architecturer ou anticiper chaque cas possible : il s'agit de créer des points de flexibilité aux endroits où le changement est le plus probable.
Le développeur optimise le code. L'architecte optimise les contraintes.
Un développeur regarde un bout de code et pense : comment le rendre plus rapide ? Plus lisible ? Plus court ? Ce sont de bonnes questions. Mais l'architecte regarde le système entier et pense : quelle est la contrainte qui, si elle était levée, changerait tout ?
Sur ce projet industriel, la contrainte principale n'était pas la performance du code. C'était la synchronisation des données entre sites avec une connexion réseau intermittente. Optimiser les requêtes SQL n'aurait rien changé. La bonne réponse était une architecture capable de fonctionner hors ligne et de synchroniser sans conflits quand la connexion revenait.
Identifier la vraie contrainte est plus difficile qu'optimiser le code. Elle est souvent implicite, rarement documentée, et parfois le client lui-même ne sait pas l'exprimer clairement.
Demander : "Qu'est-ce qui, si ça ne fonctionnait pas correctement, rendrait le système inutilisable pour vos utilisateurs ?" La réponse à cette question définit l'axe architectural principal. Tout le reste est secondaire.
Le développeur documente ce que fait le code. L'architecte documente pourquoi.
La documentation technique la plus précieuse n'est pas celle qui explique ce que fait une fonction. Le code lui-même le dit. La documentation précieuse explique pourquoi cette décision a été prise plutôt qu'une autre, quelles alternatives ont été considérées et pourquoi elles ont été rejetées.
Six mois après avoir pris une décision d'architecture, personne ne se souvient du contexte. Un nouveau développeur qui arrive sur le projet voit une décision qui lui semble bizarre et la "corrige", en réintroduisant exactement le problème que la décision originale était censée résoudre.
Les ADR (Architecture Decision Records) sont des documents d'une page qui capturent le contexte, la décision et les alternatives rejetées. Ce n'est pas une contrainte bureaucratique. C'est de la mémoire institutionnelle.
La transition ne se produit pas automatiquement
Passer de développeur à architecte n'est pas une promotion. Ce n'est pas quelque chose qui arrive après un certain nombre d'années. C'est un changement de posture qui se choisit activement.
Il commence par une habitude simple : avant d'ouvrir l'éditeur, passer dix minutes à écrire en langage naturel ce que le système doit faire, qui va l'utiliser, et ce qui ne doit jamais casser. Ces dix minutes ne remplacent pas la conception, elles la démarrent.
La différence entre les deux rôles n'est pas dans ce qu'on sait faire. Elle est dans ce qu'on fait en premier.
Je suis disponible pour des missions de conception, d'audit et d'accompagnement technique. Que ce soit en amont d'un projet ou sur une base de code existante.
Me contacter