Construire sous contraintes

Les projets intéressants commencent rarement dans un environnement propre. Il manque un schéma, un accès, une décision, parfois même une définition stable du problème.

J'essaie de livrer par couches : d'abord rendre le flux visible, ensuite stabiliser la donnée, puis automatiser ce qui se répète. Cette séquence évite de construire une belle architecture autour d'un problème encore mal compris.

Rendre visible avant d'automatiser

Quand un workflow est flou, l'automatiser trop tôt amplifie le désordre. Je préfère commencer par dessiner les états : ce qui entre, ce qui sort, qui décide, quelles exceptions reviennent souvent, et où les humains perdent du temps.

Ce travail semble lent au début, mais il accélère tout le reste. Une fois le flux visible, les priorités deviennent beaucoup plus simples : on voit ce qui doit être sécurisé, ce qui doit être calculé, ce qui doit être validé, et ce qui peut attendre.

Livrer petit, mais livrer vrai

Sous contrainte, une version utile vaut mieux qu'une vision complète jamais mise en ligne. L'important est de choisir une première tranche qui touche le vrai problème, pas seulement une partie confortable à coder.

• ■Identifier une action métier centrale.
• ■La rendre fiable de bout en bout.
• ■Ajouter des traces pour comprendre ce qui se passe.
• ■Mesurer ce qui a changé avant d'ajouter une nouvelle couche.

Ce que les contraintes apprennent

Le manque de temps force à mieux nommer les choses. Le manque de données force à poser les bonnes questions. Le manque de certitude force à construire des systèmes modifiables. Ce n'est pas confortable, mais c'est souvent là que l'architecture devient plus honnête.

Je ne cherche pas à tout prévoir. Je cherche à laisser assez de structure pour que le prochain changement ne casse pas tout.