Comment présenter beta.gouv.fr

Cette page a été réalisée sur la base de nos retours d'expériences pour aider celles et ceux qui souhaitent parler de beta.gouv.fr.

Qu'est-ce que beta.gouv.fr ?

La présentation ci-dessous est la dernière version en date. Elle est susceptible d'évoluer en fonction des retours.

Le programme beta.gouv.fr vise à aider les administrations et établissements publics à construire des services simples et faciles à utiliser, en axant leurs efforts sur les besoins des utilisateurs. Il a pour objectif de remettre les gens au coeur de l’action publique, dans le but d’apporter des solutions concrètes à leurs problèmes et d’obtenir le meilleur impact (environnemental, social, économique).

L’approche que nous proposons aux administrations, parfois surnommée “approche Startup d'État” car on y retrouve certaines des pratiques et des modes d’organisation utilisées par les entreprises du numériques, s’applique dès le stade de l’identification du problème à résoudre (problème de politique publique ou irritant au sein de l’administration). L’utilisation de cette approche dès le début d’un projet permet de réduire les risques de déployer une solution inutile, puisqu’elle consiste à prendre des décisions en fonction de données probantes, d’enseignements tirés d’expérimentations en conditions réelles sur le terrain et de la réalité vécue par les utilisateurs : tous les six mois, un comité d’investissement regroupant les partenaires détermine en fonction de l’impact mesuré du service si le service doit continuer. Cette approche se décline en général sous 4 phases :

• une phase d’investigation (6 à 9 semaines) qui permet de mieux cerner le problème à résoudre, de comprendre les besoins des personnes concernées et de déterminer les hypothèses de solutions susceptibles d’avoir le meilleur impact ;
• une phase de construction (6 à 12 mois) qui permet de tester en conditions réelles une ou plusieurs hypothèses de solutions en conditions réelles mais sur un périmètre réduit, pour se confronter le plus rapidement possible aux utilisateurs et recueillir des retours ;
• une phase d’accélération (12 à 36 mois) qui consiste à améliorer et déployer le service si son utilité est avérée, avec l’objectif de maximiser son impact ;
• une phase de consolidation qui vise à déterminer la meilleure manière de pérenniser le service, en conservant de préférence une approche centrée sur les utilisateurs dans la durée.

Aujourd’hui, plus de 250 personnes (agents publics, développeurs, designers, entrepreneurs, chargés de déploiement, animateurs de communauté, juristes, etc) travaillent au sein de la communauté beta.gouv.fr élargie, dans un réseau de 7 incubateurs.

Nos réalisations

Nous construisons des services publics numériques qui peuvent :

• Simplifier la vie des usagers (exemples : parents d'élèves et intendants grâce à Dossiersco, entreprises grâce à Mon-entreprise.fr, agents publics grâce à Zam) ;
• Rendre des politiques publiques plus efficaces grâce au levier du numérique (exemples : la lutte contre le non-recours grâce à mes-aides.gouv.fr, l'aide aux entreprises en difficulté grâce à Signaux Faibles) ;
• Construire des politiques publiques nouvelles dans des champs que la puissance publique n'avait pas investi jusqu'à présent (exemples : le développement du covoiturage avec le registre de preuve de covoiturage, l'amélioration des compétences numériques grâce à Pix.fr)

Notre impact

L'impact réel de chaque service est en général mis à jour sur une page url_startup/stats. Exemple : pix.fr/stats.

"Startup d'État" ?

L'expression Startup d'État a été employée pour la première fois en 2013, avec pour objectif d'intriguer, de susciter la conversation par cet oxymore.

Elle prête toutefois à confusion et génère souvent des malentendus : l'expression induit en erreur, puisqu'elle laisse entendre que l'État incube des startups privées, ou que les services que nous construisons ont chacune une personnalité juridique propre, ce qui n'est pas le cas.

Il est préférable d'éviter de parler de "Startup d'État" pour désigner les services développés et privilégier l'expression "services conçus selon l'approche Startup d'État". (Avec la majuscule à Startup d’État qui signifie qu’on introduit un concept entier, par opposition à startup d’État, qui laisse entendre que c’est une startup de l’État, avec toutes les questions de statut moral ; c’est comme les guillemets, mais sans l’aspect dépréciatif). Chez beta.gouv.fr, donc, nous construisons des services publics numériques, selon l'approche Startup d'État.

Approche

L'approche Startup d'État diffère de ce qui est usuellement pratiqué au sein du secteur public dans la conception de services numériques. Il est souvent contre-productif d'employer un langage jargonneux ("agile", "scrum", etc) pour décrire comment nous travaillons. Les grandes différences dans nos manières de faire sont résumées au sein du manifeste de beta.gouv.fr et peuvent être reformulées ainsi :

1. Nous cherchons constamment l'impact : les décisions et priorités des équipes sont guidées par les retours des utilisateurs et non par un cahier des charges défini une fois pour toute par l'administration. Tandis que ce dernier impose une fois pour toute un calendrier et une spécification du produit attendu, l'écoute des besoins usagers conduit à faire évoluer le service au fil de l'eau.
2. Nous constituons des équipes autonomes, responsables de leur budget et de leurs outils, et constituées d'experts du numérique travaillant au sein de l'État. En particulier, nos équipes bénéficient d'un espace de liberté pour innover, sans avoir par exemple à passer par les règles inhérentes à la structure ou par les circuits de validation habituels.
3. Nos équipes lancent le plus rapidement possible la première version d'un service afin de le confronter à de premiers usagers en vue de l'améliorer progressivement et de l'expérimenter sur le terrain. Les équipes commencent donc toujours petit avant d'envisager des ambitions nationales et universelles ! Cette approche permet d'adapter le service aux vrais besoins des utilisateurs, à découvrir des besoins que n'auraient pas pu imaginer un cahier des charges, et à garantir une utilité réelle à l'outil. Surtout, elle oblige les équipes à mettre leur service en ligne sans attendre d'avoir tout fini afin de s'assurer qu'il a vraiment de la valeur. Dans les projets informatiques classiques, souvent construits sans contact avec les utilisateurs avant sa conception complète, il arrive que le logiciel soit déjà obsolète au moment de sa sortie – ou qu'il ne résolve finalement pas le problème des usagers qui avait pourtant justifié sa commande. En adaptant le service en continu, on réduit considérablement ce risque – et les coûts qui y sont associés.

Quelques exemples

L'expression :

Méthode « startup d’État », la nouvelle manière de construire les projets de l’administration

pose problème. Matti Schneider, un ancien de la communauté beta.gouv.fr, expliquait déjà en 2016 pourquoi, en espérant que cela guidera de futurs points rédactionnels :

1. Ce n’est pas la nouvelle manière de construire mais une manière, qui ne doit surtout pas être perçue par des acteurs publics comme le moyen d’être hype sans se remettre en question. Ce n’est pas une évolution naturelle de tous les projets administratifs avec une part de numérique, mais une possibilité de construire de manière exploratoire un service encore inconnu. On reçoit déjà assez de demandes mal qualifiées comme ça, il faut limiter notre exposition.
2. Ce ne sont pas des projets mais des produits, ou éventuellement des services numériques. C’est très important : un projet a un début et une fin connues, un produit vivra et évoluera en permanence. On est sur un changement de pensée majeur pour l’administration. La notion de service est encore plus lointaine, et c’est peut-être même un peu tôt pour l’introduire, mais on peut faire le lien avec service public numérique.
3. Je ne suis vraiment pas convaincu par l’appellation de « méthode ». On a des principes, des valeurs, des exemples et des éléments de méthode, mais il ne me semble pas qu’une « Startup d’État » soit une méthode.

« Produire rapidement et durablement des outils numériques qui améliorent le service public », c’est très bien. Ou « Les Startups d’État, un moyen de construire des produits numériques qui améliorent le service public ».

Cette phrase (citation d'Hela Ghariani) peut également permettre d'expliquer simplement ce que nous faisons :

Partir d’un problème précis identifié sur le terrain, construire une équipe animée et motivée pour le résoudre et avancer pas à pas pour construire la solution et sa stratégie de déploiement.

Éviter le jargon

beta.gouv.fr est un réseau au carrefour du monde du numérique (startups, communauté du libre, etc) et de celui de l'administration bureaucratique, deux univers culturels portant en eux une série de valeurs, de principes et surtout, d'expressions linguistiques jargonneuses, souvent impénétrables par celles et ceux qui n'en sont pas.

Il est souvent tentant d'adopter le langage de ces mondes (multiplier les acronymes administratifs obscurs, discuter "open innovation", "méthodes agiles", "hackathon", "disruption") parce qu'ils sont à la mode ou qu'ils sont confortables dans une logique d'entre-soi.

Ces habitudes de langage nuisent cependant à l'objectif que nous poursuivons (améliorer le service public de l'intérieur grâce au levier du numérique) principalement à deux titres :

• elles complexifient la compréhension de ce que nous faisons par notre public (les administrations que nous accompagnons, le grand public que nous essayons d'aider, etc) et, en conséquence, ralentit la diffusion des savoirs et des bonnes pratiques ;
• elles diluent notre message dans un flot d'expressions souvent truffées d'anglicisme "à la mode", soi-disant "dans l'air du temps" mais souvent perçues comme ridicules voire excluantes, alors que la langue française permet très bien d'exprimer nos idées de manière claire et intelligible par tous.

Voici quelques exemples non exhaustifs d'expressions issues de la "culture startup" à éviter, avec à chaque fois des suggestions d'améliorations :

• "Hackathon", "openlab", "datathon" => "rencontre publique", "rencontre ouverte", "atelier de co-construction"
• "Méthodologies agiles", "lean" => "développement au plus près des besoins des usagers"
• "Pivoter" => "apprendre de ses erreurs"
• "Pitcher" => "présenter brièvement"
• "Produit", "produit numérique" => "service numérique", "outil numérique"
• KPI => "indicateurs de performance", "mesure d'impact", ou tout simplement "résultats"
• MVP ou "Produit minimum viable", "Preuve de concept", POC => "première version imparfaite du service"
• "Mettre en production" => "mettre en ligne"
• "innovation", "disruption" => éviter ce genre d'expression souvent incantatoire, notre objectif est tout simplement de "résoudre des problèmes"
• "Early stage" : "service en construction", "en expérimentation"
• "Itératif", "incrémental" => "progressif"
• "Board" => "comité d'investissement"
• "Digital" => "numérique" ("digital" est un anglicisme)
• "Bizdev" = "chargé de déploiement" (un service conçu selon l'approche Startup d'État ne propose pas seulement un produit, elle s’assure qu’il soit utilisé. Une directive/circulaire/décret/loi ne suffit pas à ce que le public connaisse et utilise un service public. Les chargés de déploiement ont ainsi pour rôle de faire en sorte que les usagers utilisent le service construit car ils y trouvent un intérêt.)