Numériser un service, pas un formulaire

Bienvenue dans ce parcours sur Scrum en pratique. Ici, on ne fait pas de théorie pour le plaisir : tu vas suivre des équipes qui transforment un service de tous les jours en service numérique. Dans cette première leçon, tu vas voir ce que veut dire numériser un service, et pourquoi beaucoup de projets échouent alors qu'ils ont livré tout ce qui était prévu. Tu vas aussi faire connaissance avec les trois équipes du cours. Enfin, on regardera les quatre préférences du Manifeste agile, qui expliquent l'état d'esprit derrière Scrum.

Prends un exemple courant. Une mairie met en ligne le PDF de son formulaire de demande. L'usager le télécharge, cherche une imprimante, le remplit à la main, puis vient quand même le déposer au guichet, aux heures d'ouverture. Sur le papier, le projet est terminé : le formulaire est en ligne. Pour l'usager, presque rien n'a changé. Numériser un service, c'est regarder tout le chemin de la personne, de son besoin jusqu'à la réponse, et retirer les étapes qui lui font perdre du temps ou de l'argent. Le formulaire n'est qu'un morceau de ce chemin.

Il faut distinguer deux choses. Le livrable, c'est ce que l'équipe produit : une page, une application, un module de paiement. L'effet, c'est ce qui change pour les gens : moins d'attente, moins de déplacements, moins d'erreurs. Une équipe peut livrer vingt écrans sans aucun effet, si personne ne s'en sert ou si l'usager doit toujours appeler pour confirmer. À l'inverse, un simple SMS de rappel peut faire baisser les absences à une consultation. Dans ce cours, avant chaque décision, demande-toi : quel effet cela aura-t-il pour l'usager, et comment je le saurai ?

Tu vas suivre trois équipes imaginaires, inspirées de situations courantes. À Dakar, une clinique de quartier veut que les patients réservent leur consultation sans passer la matinée au téléphone ou dans la salle d'attente. À Lomé, un collège privé veut que les parents paient les frais de scolarité par mobile money et reçoivent un reçu, sans faire la queue à la caisse. Au Québec, une petite municipalité veut recevoir en ligne les demandes de permis et les signalements, comme un nid-de-poule ou un lampadaire en panne. Chaque équipe a ses contraintes : réseau instable, budget serré, membres à distance.

En 2001, un groupe de développeurs a publié un texte très court, le Manifeste pour le développement agile de logiciels. Il tient en quatre préférences. Les personnes et leurs échanges comptent plus que les processus et les outils. Un logiciel qui fonctionne compte plus qu'une documentation complète. La collaboration avec le client compte plus que la négociation du contrat. Et s'adapter au changement compte plus que suivre un plan. Attention : le texte ne dit pas que les outils, la documentation ou le plan sont inutiles. Il dit qu'en cas de conflit, on donne la priorité au premier élément de chaque paire.

Scrum est un cadre de travail agile décrit par Ken Schwaber et Jeff Sutherland dans un document court, le Guide Scrum. La version de référence date de novembre 2020. Elle est publiée sous licence Creative Commons : tu peux la lire gratuitement, en français aussi. Scrum dit peu de choses, et c'est voulu. Il fixe des responsabilités, des événements et des artefacts, mais il ne te dit pas comment écrire un récit utilisateur ni quel outil choisir. Dans ce cours, on combine le Guide avec des pratiques venues d'ailleurs, et on te dira chaque fois d'où elles viennent.

Retiens trois idées. D'abord, numériser un service, c'est réduire l'effort de l'usager, pas déplacer le papier vers un écran. Ensuite, un projet se juge à son effet : moins d'attente, moins de déplacements, moins d'erreurs. Enfin, le Manifeste agile et Scrum t'aident à avancer par petites étapes, en vérifiant souvent que tu vas dans la bonne direction. Dans la prochaine leçon, tu vas apprendre à observer le parcours réel d'un usager, étape par étape, avec une montre et un carnet. C'est ce travail d'observation qui te dira par où commencer.