La start-up publique interne, un modèle d’excellence opérationnelle ?

Pourquoi se tourner vers une méthode d’incubation de ce type ?

L’insatisfaction des séances d’idéation sans lendemain

Depuis sa création, le Lab06 a réalisé de nombreuses séances de créativité et d’intelligence collective. Il a dessiné, avec les groupes qu’il a accompagnés, de nombreuses pistes d’amélioration. Cependant, une fois passée la porte du Lab06, ces idées n’ont pas toujours trouvé le chemin de leur mise en œuvre pour de multiples raisons, assez classiques finalement dans un environnement administratif : la barrière hiérarchique (les longs circuits de décision), des ressources humaines ou financières inadaptées, parfois inexistantes, un phénomène « silo » dominant. La volonté de donner réellement les moyens d’agir aux bonnes idées a donc été la phase 2 du développement du Lab06. Et c’est pour « libérer » les bonnes énergies du plafond de verre bureaucratique que nous avons observé avec intérêt le modèle de start-up publique interne.

Notre inspiration : les start-up d’État de beta.gouv

Qu’est-ce qui se cache derrière cet OVNI administratif ? Comment des services numériques « disruptifs » tels que mes-aides.gouv.fr, Reso ou La bonne boîte ont pu être conçus en quelques mois dans un environnement administratif ? Aujourd’hui, la start-up d’État s’applique à plus de soixante projets (www.beta.gouv.fr/startups). Comment ce tour de force a-t-il été possible ?

Ce modèle applique 4 grands principes qui sont des « perturbateurs positifs » du cycle de production administratif :

L’engagement : la start-up publique repose sur l’intraprenariat. Un agent public « indigné » par une problématique, qui imagine une solution et à qui on donne les moyens d’agir fera preuve d’une motivation à toute épreuve. Beta.gouv a choisi la formule de l’intraprenariat à temps complet, le Lab06 a opté pour un intraprenariat à temps partiel plus en phase avec l’acceptabilité du management en place.

Cela consiste à décharger l’agent public de tout ou une partie de ses activités habituelles, selon le format choisi, afin de lui donner le « temps » nécessaire pour la conduite du projet dont il devient le pilote. L’avantage d’un intraprenariat partiel, tel que testé au Lab06, réside dans la souplesse du dispositif (le droit à l’erreur existe vraiment : la start-up peut s’arrêter sans trop de difficulté, si la problématique initialement identifiée s’avère ne pas être la bonne, cela n’engage pas un dispositif RH lourd et consommateur de temps). L’intraprenariat partiel suppose néanmoins de sanctuariser le jour dédié au projet pour ne pas retomber dans l’injonction de l’urgence, toujours prioritaire sur l’innovation !

Le coaching : la start-up publique ne se réduit pas à l’intrapreneur. C’est une petite unité de production pluridisciplinaire (développeurs, designers, etc.) qui trouvera son rythme de croisière grâce à l’intervention d’un facilitateur, coach ou mentor, etc. Le principe est de protéger cette équipe de tous les attracteurs administratifs qui ne manqueront pas de se présenter : reporting à la hiérarchie, prise de décision par cette dernière, etc. Le rôle du coach sera de rendre l’équipe autonome, dans ses prises de décisions comme dans son pilotage, et de faire acter par l’organisation que le mode de production puisse sortir des codes habituels.

Le respect des délais : la start-up gagne en responsabilisation pour piloter son projet, mais le corollaire est qu’elle s’engage à faire la preuve de son concept dans un délai contractualisé au départ. En règle générale, six mois sont nécessaires pour concrétiser une solution et la confronter à son usage. Cela signifie que la règle du dépassement de délai, grand jeu dans la sphère publique, sera proscrite. Au bout de six mois, une évaluation est réalisée, avec des métriques qui se focaliseront sur la valeur produite : gain de temps, amélioration de l’expérience usager, indicateurs de qualité, etc. Et c’est cette étape, associant la hiérarchie, qui permettra d’acter la poursuite ou l’arrêt du projet.

L’association de l’utilisateur final : ce qui différencie également la start-up publique d’un autre modèle de gestion plus classique de projet est l’omniprésence de l’usage. Le numérique n’est pas la révolution de la technologie mais bien celle de l’expérience. Et ce qui va garantir la réussite d’un projet est la rencontre de la « solution imaginée » avec une appropriation concrète de cette solution par des utilisateurs. C’est la raison pour laquelle, dans une start-up publique, l’utilisateur n’est pas un acteur périphérique mais une partie prenante centrale : il va être écouté pour comprendre son mode de fonctionnement, ses « points de douleur », ses désirs, ses représentations, ses habitudes. Il va également être associé pour contribuer à l’amélioration continue de la solution, il sera particulièrement accompagné lors du déploiement de la solution sur le terrain.

L’apport du design et de l’agilité dans l’incubation d’une start-up publique

Le cadrage du projet en format « accélération »

Jack Knapp a partagé dans un livre intitulé Design Sprint2 son expérience de résolution collective et expérimentale de problème. Cet ingénieur, passionné par l’efficience, a au fil de son parcours professionnel construit une méthode prenant ses racines dans le bon sens et l’efficacité opérationnelle. Ayant accompagné de multiples projets et équipes, ce qui a amélioré son modèle au fil du temps, il a souhaité le diffuser : une démarche d’écoute des experts et des utilisateurs finaux, des séances de créativité rythmées, des prototypes testés avant toute réalisation, le tout dans un format court : cinq jours. Une semaine donc pour être certain du problème à résoudre et pour « tester » des pistes de solutions, avant même de se lancer... Une « preuve de concept » collaborative et accélérée.

Lorsque nous avons démarré l’incubation d’un projet issu d’un challenge innovation interne, nous avions deux contraintes fortes : une enveloppe financière serrée (25 K€) et un cycle de production court (entre quatre et six mois pour délivrer la solution). La préoccupation du Lab06 a donc été de sécuriser le cycle de production pour ne pas tomber dans des attracteurs de temps ou d’argent, deux risques d’échec que nous souhaitions minimiser au maximum.

Nous n’avions pas la possibilité de réunir durant cinq jours l’ensemble des parties prenantes compte tenu des agendas des uns et des autres (collaborateurs internes, partenaires externes). Nous avons donc adapté le cadre méthodologique de Jack Knapp sur trois jours, en conservant l’esprit de la méthodologie d’accélération mais en l’adaptant.

Un design sprint « hacké »

Nous avons réalisé une première séance « problématique et contexte », en amont, de deux heures environ, réunissant les porteurs du projet et les développeurs. Cette séance conduite comme une « investigation journalistique » a permis d’identifier les acteurs, d’approcher une première problématique de manière macro, d’identifier les risques et les leviers de réussite et de « dessiner » un premier schéma représentant la problématique et soncontexte. Cette phase est nécessairement « facilitée » par un expert en animation d’intelligence collective pour synthétiser de manière fidèle les propos tenus au cours de la séance. Nous avions ces compétences au Lab06.

Ce premier travail réalisé, nous avons organisé trois semaines plus tard, le fameux « design sprint », raccourci et adapté, et réunissant un noyau dur pluridisciplinaire (les développeurs, les deux intrapreneuses, la hiérarchie ou le sponsor, les experts, le Lab06).

Finalement, trois jours d’affilée, riches d’échanges qui ont permis d’aboutir à une vision consensuelle de notre future solution. Bien souvent, cette phase n’est pas conduite de manière pluridisciplinaire, avec des retours utilisateurs, ni dans un cycle court… ce qui lui ôte deux dimensions fondamentales : la solidarité de l’équipe sur la cible à atteindre et l’anticipation de nombreuses difficultés, avant même de démarrer.

Le diable se cache dans les détails : l’adaptation de Scrum pour passer d’une vision « macro » à une vision « micro », englobant tant la solution que le fonctionnement de l’équipe

Une fois ce cadrage « design » réalisé, nous avons adapté la méthode Scrum pour les cycles de développement. Là encore, il n’était pas question d’appliquer à la lettre des règles trop éloignées de la culture de notre organisation, mais de commencer à faire évoluer les pratiques par l’application de quatre principes à forte valeur ajoutée :

– l’écriture des « user stories » afin de décrire par le menu détail une fonctionnalité en obligeant ainsi le métier à se projeter réellement sur des usages précis. Cette méthode permet de créer une « zone de communication efficace » entre développeurs et métier. « En tant que … [profil], je réalise … [une action précisément décrite] pour obtenir … [un résultat également précisément décrit]. » Nous avons utilisé la plateforme Trello afin de partager ces user-stories pour lesquelles les développeurs pouvaient à distance demander des compléments d’information. Cela permettait également de voir l’avancée de leur réalisation durant les sprints de développement et d’ainsi conserver un lien permanent entre les membres de l’équipe ;

– la priorisation collective : chaque sprint a fait l’objet d’une priorisation consensuelle entre les priorités du métier et la capacité de réalisation des développeurs. Là encore, ces séances collaboratives de préparation sont capitales : elles permettent à deux univers d’être en écoute active et de chercher la meilleure solution pour atteindre une valeur ajoutée « réalisable » ;

– les rétrospectives : à chaque fin de sprint de développement (qui durait deux semaines), les développeurs faisaient une démonstration des user-stories qui avaient été développées ; tout le groupe évaluait également le fonctionnement de l’équipe, points forts comme points faibles afin de rester dans une démarche d’amélioration continue, y compris dans les interactions humaines ;

– le test utilisateur : chaque livrable de sprint a été systématiquement testé par des utilisateurs. Cela a permis d’inclure dans les préparations de sprint de développement des corrections et améliorations aux côtés de nouvelles fonctionnalités.

Qu’apporte ce modèle dans les organisations administratives telles que nous les connaissons ?

La start-up publique interne insuffle un nouvel état d’esprit : agir pour comprendre plutôt que comprendre avant d’agir, faire confiance et responsabiliser l’équipe en charge de la résolution d’un problème, accepter de se tromper et s’adapter, promouvoir une vision pluridisciplinaire sur un sujet qui permet de penser une problématique au-delà du carcan du grade et des savoirs supposés. Cette phrase d’Euripide : « Aucun de nous ne sait ce que nous savons tous ensemble », a encore plus de valeur dans notre environnement actuel, complexe et incertain.

Elle est également une école d’ingéniosité et une opportunité de croissance des connaissances et des savoir être. La start-up publique est un espace « apprenant » autant sur les méthodes qui dépasseront leur cadre d’exercice habituel (les développeurs apprennent aux métiers les priorisations agiles, l’écriture des user-stories, les métiers rendent lisibles pour tous les membres de l’équipe les règles, les processus, les codes et la culture d’une organisation) que sur l’aventure managériale d’un groupe humain et sur le potentiel d’intelligence collective de ce dernier. On réapprend à faire des relations interpersonnelles un sujet à part entière et à rechercher une excellence opérationnelle dans leur fluidité et qualité. Ce qui fait la force d’une équipe, c’est la qualité des relations entre les personnes, et celle-ci trouve nécessairement un point de consensus dans le sens de l’action réalisée, au-delà des différences.

En conclusion, la start-up publique, par sa taille et son autonomie, redonne à l’humain toute sa place ; ce faisant, elle contribue fortement à l’épanouissement professionnel en responsabilisant, en reconnaissant les talents et en redonnant un pouvoir d’agir aux agents publics. Cette expérience a été pour chacun de nous une aventure très riche. Pour reprendre le verbatim d’un utilisateur, lors de tests : « Pour une fois, ce n’est pas la montagne qui accouche d’une souris mais plutôt la souris qui accouche d’une montagne ! »

1. Depuis mars 2019, Magali Barnoin est responsable sud-est et secteur public chez Kereon Intelligence.
2. Knapp J., Design sprint. Résoudre les problèmes et trouver de nouvelles idées en cinq jours, 2017, Eyrolles ;