Pourquoi on construit vos logiciels brique par brique (et pas d'un seul bloc)

Vous avez peut-être déjà vécu ce scénario : une grosse boîte de dev vous vend un logiciel sur-mesure, vous signez un cahier des charges de 80 pages, vous payez 30 % à la commande, et vous attendez. Six mois plus tard, vous découvrez un outil qui ne correspond pas à ce que vous aviez en tête. Trop tard pour faire machine arrière : 70 % du budget est déjà parti.

Chez AppMinds, on construit autrement. Brique par brique. Voici pourquoi, comment, et dans quels cas cette méthode atteint ses limites.

Le piège du « tunnel »

Le tunnel, c'est cette période entre la signature et la livraison pendant laquelle le client ne voit rien. Trois mois, six mois, parfois un an. Pendant ce temps :

• Votre métier évolue : un nouvel OPCO change ses règles, votre référent Qualiopi part, vos commerciaux trouvent un nouveau canal d'acquisition. Le cahier des charges signé il y a 4 mois est déjà obsolète.
• Vos hypothèses sont fausses : on croyait que la priorité c'était le LMS. Au démarrage on s'aperçoit que le vrai goulot, c'est la facturation OPCO. Trop tard.
• Le risque est en bout de chaîne : si la livraison cale, vous découvrez les problèmes après avoir tout payé.

Le tunnel est confortable pour le prestataire, pas pour vous.

La méthode brique par brique

On découpe votre projet en modules indépendants, livrables en 4 à 8 semaines chacun. Chaque brique :

1. Apporte une valeur métier en elle-même : pas un demi-module qui attend les autres pour servir à quelque chose.
2. Est facturée et payée à la livraison : pas d'acompte sur du vent.
3. Peut s'arrêter là : si après la brique 1 vous estimez que ça suffit, on s'arrête sans pénalité.
4. Sert de base de discussion pour la suivante : on ne planifie pas la brique 2 avant d'avoir vu vivre la brique 1 en production pendant deux semaines.

Concrètement, pour un centre de formation, ça peut donner :

• Brique 1 — émargement numérique et génération des conventions : 5 semaines, 8 000 € HT. Livrée. Vous l'utilisez sur 3 sessions, vous nous remontez ce qui cloche.
• Brique 2 — suivi des indicateurs Qualiopi adossé à la brique 1 : 6 semaines, 10 000 € HT. Livrée. Vous passez un audit blanc.
• Brique 3 — portail apprenant pour les attestations et l'évaluation à froid : 4 semaines, 6 000 € HT.

À chaque étape, vous décidez de continuer ou pas. Vous gardez la main.

Concrètement, ça donne quoi ?

Quatre changements visibles dans votre quotidien :

1. Vous voyez votre logiciel grandir en temps réel. Pas d'écran noir pendant des mois. Vous pouvez le montrer à votre équipe, recueillir les premières réactions, identifier les bugs avant qu'ils ne deviennent structurels.

2. Vous payez ce qui est livré. Le risque financier reste maîtrisé. Si le premier module n'est pas à la hauteur, vous arrêtez après quelques milliers d'euros, pas après quarante.

3. Vous pouvez changer d'avis. Le marché bouge, vos priorités aussi. On peut décider après la brique 1 que la suite logique n'est plus celle prévue mais une autre. C'est même normal — c'est même souhaitable.

4. Vous accumulez de la valeur utilisable. Chaque brique est en production. Pas de « grande migration » au bout de 6 mois. Pas de big bang.

Quand cette méthode n'est pas la bonne

Soyons honnêtes : la méthode brique par brique a ses limites.

• Si votre projet est intrinsèquement monolithique (par exemple : refondre un système de paie avec des contraintes légales qui rendent toute version partielle illégale), il faut le faire d'un bloc.
• Si vous avez besoin d'une intégration profonde dès le départ entre 4 ou 5 outils, le découpage peut introduire des allers-retours coûteux.
• Si vous voulez tout cadrer à l'avance parce que votre comité de direction l'exige, le mode brique mal expliqué peut effrayer. Il faut alors le présenter comme « phase 1, phase 2, phase 3 » avec des jalons clairs.

Dans 80 % des cas pour une TPE ou PME, ces limites ne s'appliquent pas. Et dans les 20 % restants, il existe presque toujours un découpage moins évident mais possible.

Par où commencer

Si vous avez un projet logiciel en tête, posez-vous trois questions :

1. Quel est le problème que vous résolvez en priorité ? Pas le plus gros, pas le plus visible — le plus douloureux au quotidien.
2. Quelle est la plus petite version qui résout ce problème ? Si vous ne pouvez pas la décrire en une phrase, c'est qu'elle n'est pas assez petite.
3. Combien de temps pouvez-vous attendre avant de voir un résultat ? Si la réponse est « plus de 8 semaines », c'est probablement que le découpage est mal fait.

À partir de là, on peut en discuter — sans engagement, sans cahier des charges de 80 pages. Un appel de 30 minutes suffit pour savoir si une brique est faisable.