Régulièrement, se présentent à nous des candidats pour des recrutements sur des postes en développement ou gestion de projet. Pour qui l’étonnement est fréquent : vous travaillez en agile ? Vraiment ? Dans l’administration ?? La réponse est aisée : oui cher candidat, nous avons abandonné depuis quelques années déjà les méthodes de développement dites traditionnelles au profit de l’agilité. En préciser les détails se complique.

Alors d’abord, pourquoi l’agile sur service-public.fr ? L’agile porte pour nous une promesse : celle de commencer par le monde réel, c’est-à-dire les usagers, les citoyens, vous/nous. Afin de mieux prendre en compte leurs besoins, leurs difficultés et de traiter prioritairement les « irritants ». Bref, ne plus concevoir « pour » mais « avec » les usagers.

Tenir les promesses de l’agile passe par des changements parfois radicaux pour une structure administrative. Il s’agit de mettre en place la bonne organisation qui libère les forces, réduit les lenteurs des processus de décisions, décloisonne les traditionnelles dichotomies entre maîtrise d’œuvre et maîtrise d’ouvrage (en gros la DSI vs. les équipes produit et/ou métiers). Pour cela, différents formats s’offrent aux organisations, avec leurs nouveaux modes de pilotage et de mobilisation de toutes les parties prenantes :

  • Incubateurs de services numériques pour les uns, sur le mode startup d’État.
  • Filière digitale pour d’autres, comme à la CNAMTS
  • Co-localisation des équipes sur un plateau agile. C’est le cas de service-public.fr.


Cette organisation nous permet d’être en capacité de répondre aux priorités du moment qu’elles soient réglementaires ou issues de la détection d’irritants. Elle exige la présence et le travail collaboratif des principaux intervenants, chefs de projet, product owner, développeurs, experts… au même endroit et au même moment :

equipe_sp.png

Pour finir cette première partie, quelques pré-requis ou indispensables tirés de notre expérience sur service-public.fr :

  • Il existe toujours un MVP (produit minimum viable).
  • Il faut accepter de ne pas mettre en ligne 100% du périmètre et au contraire procéder par itérations.
  • L’infrastructure doit être prévue et mise en place de manière à pouvoir déployer sereinement et régulièrement.