Développer un système de gestion par phases : choisir ce qui entre dans la première version

La question « qu’est-ce qu’on met dans la première version » reçoit presque toujours la même mauvaise réponse : un peu de tout. Un bout de fiches, un bout de commandes, un bout de stock. C’est le choix qui paraît le plus prudent et c’est celui qu’on ne peut pas utiliser : aucun processus n’arrive jusqu’au bout, et le système reste une chose de plus à remplir en plus de ce qu’on fait déjà.

Le critère est inverse : la première version couvre un processus entier, du début à la fin, même s’il est restreint. Mieux vaut peu et complet que beaucoup et interrompu.

Un processus entier, avec un résultat visible

« Entier » a un sens précis : celui qui l’utilise doit pouvoir arrêter d’utiliser la méthode d’avant pour ce bout de travail. Si, après avoir saisi les données dans le système, on continue à remplir aussi la feuille habituelle, la première version n’est pas terminée : c’est un double travail, et il sera abandonné dès que l’entreprise connaîtra une semaine difficile.

Le résultat doit être visible pour quelqu’un : un document qui sort, une liste qui n’existait pas avant, un appel téléphonique qui n’est plus nécessaire. Cela sert à deux choses à la fois : cela donne une raison concrète d’utiliser le système et cela apporte la preuve que le projet avance quelque part.

Séparer l’indispensable des améliorations

Les demandes arrivent toutes ensemble et toutes urgentes. Il faut des questions qui tranchent, et ce sont toujours les quatre mêmes.

• Sans cette fonction, le processus s’arrête-t-il ? Si quelqu’un peut faire la même chose autrement, pour l’instant, ce n’est pas indispensable.
• Qui l’utilise, et à quelle fréquence ? Les fonctions dont on a besoin deux fois par an peuvent rester manuelles longtemps, et restent souvent manuelles pour toujours sans que personne ne s’en plaigne.
• Si elle manque, que se passe-t-il vraiment ? « On perd du temps » et « on ne peut pas facturer » ne sont pas la même réponse.
• Est-ce une fonction ou une habitude ? Il arrive de devoir reproduire une étape qui n’existait que parce que l’ancien outil ne savait pas faire autrement.

Attention aux demandes courtes qui traînent tout un monde derrière elles : un statut supplémentaire sur un document peut exiger des permissions, des alertes, un historique et une règle sur qui peut le changer. Le coût ne se mesure pas à la longueur de la phrase qui le décrit.

Les dépendances qu’on ne peut pas remettre à plus tard

La livraison par modules ne fonctionne que si certaines décisions sont prises tout de suite, même quand elles concernent des parties qui arriveront bien plus tard. Elles sont peu nombreuses, et les changer plus tard coûte autant que tout refaire.

• Les données partagées : comment on identifie un client, un article, une affaire. Si la première version invente sa propre numérotation, la seconde devra réconcilier deux archives.
• Qui voit quoi : les permissions se conçoivent dès le début, même si au départ le système n’est utilisé que par trois personnes. Les ajouter après signifie revoir chaque écran.
• D’où viennent les données qui ne naissent pas ici : si les stocks se trouvent ailleurs, on décide maintenant qui fait autorité sur une quantité, même si la liaison viendra plus tard.
• Comment on enregistre l’historique : s’il faut savoir qui a changé quoi, cela doit être prévu tout de suite, parce qu’on ne peut pas le reconstituer a posteriori.

Exemple : première version pour les affaires

Une entreprise qui installe des équipements veut un système de gestion pour ses affaires. La liste des souhaits contient une vingtaine de fonctions. La première version en retient quatre, mais va jusqu’au bout.

Les fonctions laissées de côté ne sont pas supprimées : elles restent listées, avec le motif à côté et la condition qui les fera rentrer. C’est la différence entre remettre à plus tard et oublier, et c’est aussi ce qui permet de répondre à ceux qui les avaient demandées.

Critères d’acceptation : comment on dit que c’est fini

« Ça fonctionne » n’est pas un critère. Un critère est une phrase que n’importe qui peut vérifier, écrite avant de commencer à développer.

1. Décrire le cas réel, pas la fonction : « le chef de chantier ouvre l’affaire à partir d’un devis accepté, attribue l’équipe et remplit le rapport depuis son téléphone, sur le chantier ».
2. Dire qui vérifie : celui qui fera ce travail tous les jours, pas celui qui a commandé le projet.
3. Inclure les cas tordus : l’affaire annulée, le rapport rempli sans réseau, l’intervention dont la date est déplacée.
4. Établir avec quelles données on teste : des données réelles et récentes, parce que celles qu’on invente sont toujours plus ordonnées que la réalité.

Les demandes qui arrivent en cours de route

Elles arriveront, et c’est bon signe : cela signifie que quelqu’un utilise le système. Le problème n’est pas de les recevoir, c’est de les classer rapidement.

• Erreur : ce qui existe ne fait pas ce qui avait été convenu. On corrige tout de suite.
• Oubli : c’est nécessaire au processus et personne ne l’avait mentionné. On évalue si ça entre, et la date de livraison bouge en conséquence.
• Amélioration : ça rend le travail plus confortable. Ça va dans la liste, pas dans la version en cours.
• Changement de cap : l’entreprise a changé sa façon de travailler. Ça doit être discuté à part, parce que ce n’est pas une demande mais un autre projet.

Sans cette distinction, chaque demande devient urgente et la première version ne sort jamais. C’est la façon la plus courante dont ces projets s’arrêtent : non pas à cause d’un obstacle technique, mais par accumulation.

Ce que ce guide ne couvre pas

Ici, il est question de périmètre et de séquence : ce qui entre dans la première version, ce qui est reporté et dans quel ordre. Les essais à faire avant de s’en remettre à un système au quotidien sont un chapitre à part. Et si la fonction à évaluer concerne l’usage d’un assistant automatique, les critères de jugement sont différents, parce que le résultat n’est pas prévisible de la même façon.