Pourquoi avancer par petites livraisons

Beaucoup de projets de numérisation suivent le même scénario : un long cahier des charges, des mois de développement, puis une grande livraison où l'on s'aperçoit que le service ne correspond pas aux besoins. Scrum propose une autre façon de faire : livrer une petite partie utile, regarder ce qui se passe, puis ajuster. Dans cette leçon, tu vas comprendre l'idée d'empirisme, les trois piliers sur lesquels Scrum repose, et pourquoi une petite première version réduit le risque. Tu verras aussi comment choisir cette première version sans la vider de son intérêt.

Imagine un collège d'Abidjan qui commande une application complète : inscriptions, notes, paiements, emploi du temps. Le prestataire travaille douze mois sans rien montrer. Le jour de la livraison, on s'aperçoit que le paiement ne fonctionne pas avec l'opérateur choisi par les parents, que les enseignants trouvent la saisie des notes trop longue, et que la direction a changé entre-temps. Tout le budget est dépensé. C'est ce qu'on appelle un projet tunnel : on entre d'un côté, on sort de l'autre, et on ne voit rien entre les deux. Les erreurs coûtent alors le plus cher possible.

Le Guide Scrum dit que Scrum repose sur l'empirisme et sur la pensée Lean. L'empirisme, c'est décider à partir de ce qu'on observe, pas de ce qu'on avait imaginé au départ. La pensée Lean, c'est réduire le gaspillage et se concentrer sur l'essentiel. Quand tu numérises un service, tu ne sais pas d'avance comment les usagers vont réagir. Les patients de Dakar vont-ils vraiment réserver en ligne ? Les parents de Lomé feront-ils confiance au reçu électronique ? Personne ne le sait avant d'avoir essayé. Alors on essaie petit, on regarde ce qui se passe, et on décide de la suite avec des faits.

Le Guide Scrum décrit trois piliers. La transparence d'abord : tout le monde voit le même état du travail, sans maquillage. Un tableau au mur où chaque tâche est visible en est un bon exemple. L'inspection ensuite : on regarde souvent le produit et l'avancement, pour repérer les écarts tôt. Enfin, l'adaptation : dès qu'on voit un écart, on corrige, le plus vite possible. Les trois se tiennent. Une inspection sans transparence trompe l'équipe, parce qu'elle regarde une image fausse. Et une inspection sans adaptation ne sert à rien : on a vu le problème, mais on n'a rien changé.

Plus une erreur est découverte tard, plus elle coûte cher. Si l'équipe de Lomé montre aux parents, au bout de deux semaines, un premier écran de paiement, et qu'ils ne comprennent pas le mot référence, on change un mot et une explication. Si le même problème apparaît après un an, il faut peut-être revoir tout le parcours, les reçus et les rapports comptables. Livrer souvent, c'est apprendre souvent. Chaque livraison courte est une occasion de vérifier que l'équipe construit la bonne chose, avant d'y mettre plus d'argent et plus de temps.

Attention à ne pas confondre petite version et version inutile. Un bouton de paiement qui n'envoie pas de reçu n'est pas utilisable. La bonne première version couvre un seul parcours, mais en entier. Pour la municipalité québécoise, ça peut être : un citoyen signale un nid-de-poule avec une photo et l'adresse, et il reçoit un accusé de réception par courriel. Pas de compte, pas de carte interactive, pas de suivi détaillé. Mais c'est utilisable dès la deuxième semaine, et l'équipe apprend déjà combien de signalements arrivent et comment les agents les traitent.

Retiens que Scrum décide à partir des faits observés, et qu'il s'appuie sur trois piliers : transparence, inspection et adaptation. Une erreur vue tôt coûte peu, une erreur vue tard peut coûter tout le projet. Et une première version doit être petite, mais complète du début à la fin d'un parcours. Tu as maintenant les bases du module. Fais le lab, où tu vas observer un vrai service et écrire sa vision, puis la simulation, qui se passe à Conakry, et le quiz. Au module 2, tu vas mettre en place l'équipe Scrum et son calendrier.