La plupart des premiers projets de plateforme échouent avant la technique. Ils échouent parce que l’on a additionné les demandes de quatre services différents, produit un cahier des charges de quarante pages, et découvert au bout de six mois que personne ne savait dire à quoi ressemblait le succès.
Cinq questions évitent la plus grande partie de ce gâchis. Elles se traitent en deux ateliers.
Qui est l’utilisateur prioritaire ?
Pas « les utilisateurs » : un utilisateur. Celui dont le quotidien change le plus si l’outil existe, et qui l’ouvrira tous les jours. Les autres profils viendront ensuite.
Un outil conçu pour trois populations à la fois finit systématiquement trop générique pour chacune. Choisir un utilisateur prioritaire n’exclut personne définitivement : cela ordonne le travail.
Quel problème revient assez souvent ?
Un logiciel est rentable quand il traite un problème fréquent. Une situation qui survient trois fois par an ne justifie pas une interface : elle justifie une procédure écrite.
La bonne unité de mesure est le nombre d’occurrences par semaine, et le temps consommé à chaque fois. Ce chiffre, même approximatif, indique immédiatement si le projet mérite d’exister.
Quelle donnée est critique ?
Toute plateforme repose sur une donnée centrale : le dossier, le client, l’opération, le contrat. Identifier laquelle, et qui en est la source de vérité, évite le scénario le plus fréquent : deux systèmes qui portent la même information sans jamais être d’accord.
C’est aussi le moment de repérer les données sensibles. Les rôles et les permissions se conçoivent au début, quand le modèle est simple, jamais après coup.
Qui est responsable de quoi ?
Un produit sans propriétaire dérive. Trois responsabilités doivent être nommées dès le départ, et pas nécessairement portées par la même personne.
- Qui arbitre le périmètre et dit non aux ajouts ?
- Qui répond aux utilisateurs quand quelque chose ne fonctionne pas ?
- Qui décide des évolutions une fois la V1 en ligne ?
Combien coûtera-t-il à faire vivre ?
Le développement est un investissement ponctuel ; l’exploitation est une charge permanente. Hébergement, sauvegardes, mises à jour de sécurité, support, évolutions réglementaires : cette ligne doit exister au budget avant le lancement, pas après le premier incident.
Un ordre de grandeur utile : prévoir chaque année entre 15 et 25 % du coût de construction initial pour maintenir un outil en bon état de marche. En dessous, la dette s’accumule.
Ce qu’une V1 raisonnable contient
Une première version réussie n’est pas une version pauvre : c’est une version complète sur un parcours. Mieux vaut un parcours irréprochable que six parcours à moitié faits.
| Dans la V1 | Plus tard |
|---|---|
| Le parcours de l’utilisateur prioritaire, de bout en bout | Les parcours des profils secondaires |
| Authentification, rôles et journalisation | Personnalisation fine des permissions |
| Les deux ou trois intégrations indispensables | Le reste du système d’information |
| Les indicateurs d’usage | Les tableaux de bord avancés |
| Un export des données | Les rapports sur mesure |
À retenir
- Un utilisateur prioritaire, un parcours prioritaire : le reste attend.
- Comptez les occurrences par semaine : la fréquence justifie le projet, pas l’envie.
- Nommez la donnée centrale et sa source de vérité dès le cadrage.
- Trois responsabilités à attribuer avant de commencer : arbitrage, support, évolution.
- Budgétez 15 à 25 % du coût initial par an pour l’exploitation.