Logiciel sur-mesure : comment cadrer un projet pour éviter l’usine à gaz

Pourquoi autant de projets sur-mesure dérapent ?

 

Je suis fondateur et CTO. Une partie non négligeable de mon temps consiste à analyser des projets qui, à l’origine, étaient annoncés comme “simples”… jusqu’à devenir impossibles à faire évoluer sans tout casser.   Dans l’immense majorité des cas, le problème n’est pas la technologie. Le problème, c’est le cadrage : trop flou, trop tardif, ou trop complaisant.   Voici comment j’aborde le cadrage d’un logiciel sur-mesure ou d’une plateforme SaaS quand l’objectif est clair : livrer quelque chose d’utile, maintenable et scalable.

1) Partir du problème réel, pas de la solution fantasmée

 

Un cadrage qui commence par “on veut une plateforme avec…” est toujours un signal d’alerte.   Un bon cadrage commence par le problème métier : qui est bloqué aujourd’hui, à quel moment, avec quels volumes, et quelles contraintes réelles.   Sans données concrètes (fréquence, volumétrie, charge, criticité), on fait de l’architecture au ressenti.   Et le ressenti ne tient jamais longtemps en production.

2) Écrire le non-scope (sinon le périmètre s’étendra tout seul)

 

Tout ce qui n’est pas explicitement exclu finit tôt ou tard par être demandé.   Ce n’est ni un problème de client, ni un problème de produit. C’est juste de la gravité projet.   Un cadrage sérieux inclut des exclusions claires :

Pas de multi-langues en V1
Pas de reporting avancé au lancement
Pas d’intégration ERP en première phase

Dire non tôt permet d’éviter des discussions beaucoup plus coûteuses plus tard.

3) Identifier et isoler le cœur métier

 

En architecture, tout n’a pas la même valeur.   Le cœur métier est la partie du système qui porte réellement la valeur business.   Ce cœur métier doit être :

isolé
testable
peu couplé à l’UI et aux outils externes

Si changer un écran, une API ou un prestataire met en danger les règles métier, alors l’architecture est déjà trop fragile.

4) Trancher tôt les décisions qui conditionnent toute l’architecture

 

Certaines décisions ne sont pas de simples détails techniques.   Ce sont des choix structurants qui impactent toute la stack :

SaaS ou outil interne ?
Mono-tenant ou multi-tenant ?
Niveau de disponibilité attendu ?
Données sensibles ou non ?

Les repousser, c’est construire sans fondations en espérant que ça tiendra quand même.

5) Traiter les intégrations comme de l’architecture

 

ERP, CRM, paiement, IAM, outils tiers… Les intégrations sont l’une des principales sources de complexité dans un projet sur-mesure.   Une intégration saine repose sur :

des contrats clairs
de l’idempotence
de la résilience (timeouts, retries)
de la traçabilité

Une intégration bricolée finit toujours par devenir un point de rupture.

6) Penser le run dès le cadrage

 

Un logiciel qui fonctionne uniquement sur le poste du développeur n’est pas un produit.   En SaaS, le produit inclut :

l’observabilité
la CI/CD et le rollback
la sécurité et la gestion des secrets
la gestion des incidents

Le produit, ce n’est pas le code.   Le produit, c’est le code qui tourne bien, tous les jours.

7) Découper en versions réellement livrables

 

Une V1 doit apporter de la valeur, même imparfaite.   Un projet qui attend d’être “complet” avant d’être utilisé est un projet qui n’apprend rien.   Un découpage sain ressemble souvent à :

V0 : validation de la compréhension
V1 : valeur métier minimale en production
V2 : industrialisation et montée en charge

Conclusion

 

Un logiciel sur-mesure n’est pas condamné à devenir complexe.   Il le devient quand on évite de trancher, quand le périmètre n’a pas de limites, et quand l’architecture est laissée à l’improvisation.   Un bon cadrage, ce n’est pas plus de documents.   C’est plus de décisions claires, prises tôt, et assumées.