BLOG | L’agilité pour la sphère publique : Comment réussir ?

Une vague de fond « Agilité » révolutionne actuellement le monde de l’IT au sens large impliquant l’application de ces méthodes (de manière plus ou moins rigoureuse d’ailleurs) à la majorité des nouveaux projets. En caricaturant, nous arrivons à un véritable tournant où le fait de déclarer un projet comme étant « Agile » porterait en lui les garanties de succès futur.

Même si l’Agile bien maitrisé renforce les garanties de succès, il n’en demeure pas moins que des facteurs tout aussi déterminants doivent continuer à être pris en compte, d’autant plus au sein de la sphère publique qui répond à bon nombre de spécificités, règlementaires notamment.

L’Agilité est rapide, fluide, inventive, elle est née dans le monde numérique ; les Marchés Publics sont structurés pour mettre sous contrôle les risques juridiques de l’acheteur public. Peut-on les réconcilier?

D’autre part, les sujets de la sphère publique ont leurs caractéristiques propres : légalité, conformité règlementaire, gestion de l’argent public. Le métier impose ses lois.

Notre double expérience de  conseil et maître d’œuvre de projets digitaux dans la sphère publique nous a montré que la mise en œuvre des méthodes agiles doit être progressive, ajustée et adaptée à la fois à la contrainte des marchés publics (maîtrise des coûts et des délais, engagements), à la maturité et la culture de l’organisation, et à la nature des projets concernés.

Alors, quels sont les fondamentaux pour réussir un projet agile au sein de la sphère publique ?

Intégrer les implications du changement de paradigme dans l’ingénierie de construction de la solution

La démarche cycle en V repose sur des concepts de conduite de projet similaires à ceux du BTP.

Elle en partage d’ailleurs des termes « maîtrise d'ouvrage », « maîtrise d’œuvre », etc. Une phase amont de « bureau d’études » a pour objectif de dresser le plan de l’objet à construire, de modéliser et réaliser les tests nécessaires (résistance, etc.). La phase de construction consiste alors à ordonnancer et réaliser les procédés de construction successifs pour aboutir au résultat voulu.

L’Agile est fondamentalement différent en termes de procédé. Il se rapproche de la phase développement R&D.

Dans ces démarches, il s’agit tout à la fois de préciser l’objet à construire, de définir et mettre au point les procédés de construction, voire d’expérimenter certains sujets.

« Je ne perds jamais ! Soit je gagne, soit j’apprends »

L’enjeu devient, en réalité, la convergence de ce processus itératif. L’expérimentation voire l’erreur devient, si elle est contrôlée, le moyen de progresser vers le résultat. Alors que dans le cycle en V, l’erreur de conception est un « déraillement » du procédé engendrant retard, surcoût, etc.

Le Chef de Projet est mort, vive le Projet Owner !

Ce changement de paradigme du procédé de construction implique une évolution dans le positionnement des acteurs du projet et plus généralement de l’organisation.

Ceci est particulièrement notable pour le pilotage du projet « Le Product Owner n’est pas un chef de projet ! »

Dans le cycle en V, le chef de projet est en charge de s’assurer que le processus de construction se déroule en conformité aux plans et de gérer les ajustements. Il s’appuie/ reporte sur le comité de pilotage pour toute décision « importante » nécessitant arbitrages.

En Agile, le Product Owner (PO) porte la définition itérative du produit. Son mandat est de livrer à ses clients un produit répondant aux objectifs stratégiques. Le comité de pilotage n’est plus l’instance décisionnaire mais son client à qui le PO présente régulièrement le produit pour valider que le résultat convient et le cas échéant demander des ajustements, allouer des ressources supplémentaires (ou en retirer).

Idéalement, on est dans un mode opératoire proche de « l’intrapreunariat ».

De nombreuses structures publiques ont déployé leur « innovation lab » pour tester ce mode de fonctionnement engrangeant les premiers succès. Un des enjeux est de s’appuyer sur ces retours d’expérience pour passer à l’échelle industrielle.

Adapter l’Agile au contexte du projet et à la complexité règlementaire

La démarche Agile par construction est bien adaptée à des équipes de taille réduite opérant en mode « commando » (dans l’idéal 3 à 5 développeurs, parfois, même réunis dans une « war room »). Elle apporte une visibilité immédiate sur l’avancement (morning meeting, sprint release, etc.).

Ceci permet de mettre en place des boucles de correction à cycle très court (ex: évolution user stories, modification des priorités, etc.). Cette démarche agile doit être adaptée au contexte du projet pour en sécuriser l’exécution.

De manière simplifiée, on peut identifier 3 typologies de projets :

• Les projets « Expérimentaux », où l’on peut déployer des démarches très proches des standards (Manifeste Agile).
  Le périmètre du projet se « construit en marchant », la démarche Agile et ses rituels apportent toute leur valeur.
  La sécurisation du projet sera faite par les délais (résultat attendu en x semaines ou mois).
  
• Les projets « petits et moyens » de développement de services digitaux (budget cible 300 à 1000h.j), on va y déployer des démarches de type « itérative agile ». On s’appuie sur les mécanismes de l’Agile : organisation (PO, SCM, etc.), rituels, backlog, découpage en release, sprints, identification de MVP (Minimum Viable Product), etc. pour construire la solution.
  La solution cible a été cadrée pour borner le périmètre, les moyens, le planning, le MVP, etc.
  
• Les projets « importants » (budget développement > 1000h.j), sur lesquels il faudra déployer des des démarches de conduite de projet adaptées.
  Le projet (programme) est découpé en une série de chantiers. Chaque chantier est mis en œuvre avec une démarche adaptée au cas d’espèce.
  
  La « synchronisation » des chantiers relevant du pilotage programme selon la démarche appropriée (par exemple « Agile at scale » si taille limitée, « Safe » sur gros projet de plusieurs dizaines de développeurs, etc.)

En particulier, la bonne prise en compte d’une règlementation souvent complexe (ex. les codes applicables) est un point d’attention pour les dispositifs numériques publics.

Faute de simplifications règlementaires, ceci se traduit par des spécifications, règles de gestion, etc. dont la mise en œuvre SI peut être lourde, et peu adaptée avec un cycle agile court.

La prise en compte de cette complexité repose sur une démarche d’urbanisation, où ces règles sont mises en œuvre au travers d’API de service avec back-office métiers et des contrats d’interfaces.

Si cette urbanisation n’a pas été initiée, ce sera un prérequis au projet agile, qu’il conviendra d’ordonnancer avec le calendrier du projet Agile en parallèle avec d’éventuelles simplifications règlementaires

Sécuriser l’exécution contractuelle et budgétaire

Enfin la sécurisation de la relation contractuelle avec les MOE de développement est à anticiper.

La philosophie générale du « Manifeste Agile » repose sur le concept d’une solution affinée durant les sprints. Si ce paradigme est porteur, il présente des risques sur la capacité à « converger » sans générer des dérives calendaires ou budgétaires.

Certains MOE y voient une opportunité pour passer à un engagement de moyens sur une capacité (par exemple nombre de sprints x nombre de développeurs) en lieu d’un engagement de résultats comme le demande le code des marchés.

Si un engagement ferme sur un périmètre évolutif est illusoire, de nombreuses dispositions peuvent être implémentées pour sécuriser la relation contractuelle dans un cadre de marchés publics et ainsi servir de base à la construction d’un cadre permettant de « contrôler » au mieux un triangle « périmètre / budget / délai » non figé au départ.

En amont en s’appuyant sur le cadrage, il convient de définir :

• Un contrat (CCTP, CCAP, etc.), reposant sur un périmètre d’engagement le plus précis possible (exemple : MVP, périmètre macroscopique d’EPICS, etc.)
  
• Des modalités d’ajustements (métriques, gestion des écarts, capacité à  forfaitiser des sprints en résultat et non en capacité, etc.) anticipant ces évolutions

Durant l’exécution, ces métriques d’exécution doivent permettre de mesurer  l’efficacité du MOE.

La mesure simple de l’avancement (mesure de vélocité, burnout chart, etc.) permet de suivre la progression du projet, constater la vélocité, ajuster si besoin le contenu des sprints.

Le client  ne doit pas se contenter de constater la vitesse de production et d’ajuster le tir en conséquence.

La transparence « contractualisée » par l’agile permet avec des techniques d’analyse simples par « valeur acquise » d’évaluer la qualité de l’équipe MOE et sa productivité.

Ceci est indispensable pour identifier dans l'équipe MOE les causes racines de certains problèmes (exemple : qualification et productivité de certains développeurs) et exiger du MOE un plan de correction de sa responsabilité (exemple : remplacement d’un intervenant).

Ainsi, bien au-delà du pur projet agile, il est nécessaire de déployer une organisation favorisant l’intelligence collective et une vraie flexibilité de pilotage. Il est aussi majeur de pouvoir mesurer les avancées du projet et de toujours garder en tête les spécificités propres à la sphère publique.

Telle l’Agilité en elle-même, la mise en place de cette culture projet au sein d’une organisation doit être progressive et itérative !