Le vrai problème n’est presque jamais technique
Sur les applications métier que nous reprenons après un échec, la cause est rarement le code. C’est l’écart entre le processus décrit en réunion et le processus réel. Le premier est linéaire et propre ; le second est plein d’exceptions, de contournements et de règles tacites que personne ne pense à mentionner.
C’est pourquoi notre phase d’immersion se passe sur le terrain, avec les personnes qui saisissent les données, pas seulement avec celles qui les consultent.
Ce qui distingue une application qui dure
Un modèle de données correct dès le départ. Une erreur de modélisation se paie pendant toute la vie de l’application. Nous consacrons une semaine entière au schéma relationnel, relu avec vos référents métier, avant d’écrire du code.
Des droits pensés par ressource, pas par écran. Masquer un bouton n’est pas une sécurité. Les permissions sont vérifiées côté serveur, sur chaque action, avec des politiques testées automatiquement.
Un journal d’audit dès la première version. Qui a modifié quoi et quand. Ajouté après coup, il est incomplet et donc inutile lors du premier litige.
Livrer tôt, même partiellement
Nous découpons le périmètre de façon qu’un premier module soit réellement utilisable entre la sixième et la huitième semaine. Cela produit trois effets : les utilisateurs se forment progressivement, les erreurs de conception se découvrent tant qu’elles sont peu coûteuses à corriger, et le projet démontre sa valeur avant d’avoir consommé tout son budget.
