Agile dans un projet public : ce qui marche, ce qui coince

Il y a une contradiction apparente entre l'agilité et la commande publique. L'agilité repose sur l'idée qu'on découvre le besoin en avançant. Le marché public repose sur un cahier des charges signé, un prix ferme et un calendrier. Prétendre que la contradiction n'existe pas mène droit aux conflits de recette.

Elle se traite, à condition de dire où passe la frontière.

Ce qui est contractuel, ce qui est ouvert

Nous distinguons systématiquement deux niveaux.

• Le quoi et le pourquoi sont contractuels. Les fonctions à couvrir, les volumes, les niveaux de service, les échéances : c'est le cahier des charges, il ne bouge pas sans avenant.
• Le comment reste ouvert. L'enchaînement des écrans, le libellé des champs, l'ordre de livraison des modules, la façon dont un contrôle est présenté à l'agent : cela se décide en avançant, avec les utilisateurs.

Cette distinction, posée dès la réunion de lancement, désamorce l'essentiel des tensions. Le commanditaire garde la maîtrise de son engagement ; l'équipe garde la liberté d'ajuster ce qui ne se décide bien qu'en voyant le produit.

Le rythme qui fonctionne

Des itérations de deux semaines, avec à chaque fin une version installée sur un environnement accessible au client — pas une démonstration sur le poste du développeur. La différence est considérable : un utilisateur qui manipule découvre en dix minutes ce qu'aucune réunion de spécification n'aurait fait remonter.

Trois rendez-vous suffisent :

• un point de cadrage en début d'itération, pour convenir de ce qui sera livré ;
• un point court chaque semaine entre les référents métier et l'équipe, pour lever les blocages ;
• une démonstration en fin d'itération, suivie des remarques écrites.

Ce qui coince réellement

La disponibilité des référents métier. C'est le premier facteur d'échec, loin devant la technique. Une équipe agile sans interlocuteur métier disponible devient une équipe qui invente le besoin. Nous demandons un référent nommé, avec un temps identifié dans sa fiche de charge, et nous le disons dès l'offre.

La comitologie. Dans une institution, une décision remonte. Si chaque arbitrage d'écran attend le comité de pilotage mensuel, le rythme de deux semaines n'existe plus. La solution est de définir à l'avance ce que le référent peut trancher seul.

La recette. Une recette conduite en une fois, à la fin, sur six mois de développement, produit une liste d'anomalies impossible à traiter dans les délais. Une recette continue, par itération, étale la charge et révèle tôt les malentendus. Cela demande d'engager les futurs utilisateurs bien avant la mise en service.

La reprise de l'existant. Les données héritées sont le point qu'on sous-estime toujours. Elles arrivent en retard, incomplètes, avec des règles implicites que personne ne sait formuler. Nous traitons désormais la reprise comme un chantier à part entière, démarré au premier tiers du projet, jamais à la fin.

Le rôle de la documentation

L'agilité a été mal comprise sur ce point : elle privilégie le produit fonctionnel à la documentation exhaustive, elle ne la supprime pas. Pour une administration qui devra exploiter, faire évoluer et éventuellement remettre en concurrence la maintenance, la documentation d'architecture, les procédures d'exploitation et le transfert de compétences font partie du livrable. Nous les produisons au fil de l'eau, pas dans les trois derniers jours.

En résumé

L'agilité en contexte public ne consiste pas à s'affranchir du cadre, mais à décider ce qui se fige et ce qui reste vivant. Les projets qui échouent ne sont presque jamais ceux qui ont mal choisi leur méthode : ce sont ceux où personne n'a dit clairement qui décide quoi.