-
Notifications
You must be signed in to change notification settings - Fork 1k
Comment présenter beta.gouv.fr
=> En résumé : "Startup d'État" est à considérer comme une marque ou une approche.
L'expression "Startup d'État" a été employée pour la première fois en 2013, avec pour objectif d'intriguer, de provoquer la conversation. Elle prête toutefois à confusion : qu'est-ce qu'une "Startup d'État" ? est-ce une entreprise privée financée par des fonds publics ? quel est son statut juridique ?
Le plus souvent, la "Startup d'État" n'a pas de personnalité juridique. Il s'agit simplement d'une équipe en charge de résoudre un problème, hébergée au sein de l'État, qui utilise un certain nombre d'éléments de méthodes, d'outils, de pratiques développées par les entreprises du numérique, et notamment par les startups privées, pour apporter le maximum de valeur aux usagers.
Pour mieux faire comprendre tout cela, il est possible d'éviter de parler de "Startup d'État" pour désigner les services développés, mais de privilégier l'expression "approche Startup d'État". (Avec la majuscule à Startup d’Étatn 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).
Ainsi l'expression :
pose ainsi problème. Matti Schneider, un ancien de la communauté beta.gouv.fr, l'expliquait déjà en 2016 pourquoi, en espérant que cela guidera de futurs points rédactionnels :
- 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.
- 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.
- 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 ».
Une bonne manière de présenter beta.gouv.fr, c'est d'insister sur l'impact de nos réalisations plutôt que de la méthode.
Ainsi, nous construisons des services publics numériques qui peuvent :
- Simplifier la vie des usagers (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 (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 puisance publique n'avait pas investi jusqu'à présent (le développement du covoiturage avec le registre de preuve de covoiturage, l'amélioration des compétences numériques grâce à Pix.fr)
L'impact réel de ces services numériques est en général mis à jour sur une page url_startup/stats. Exemple : pix.fr/stats.
Il y a probablement des moments où il vous faudra détailler les éléments de méthode de l'approche Startup d'État. Pour illustrer cette différence, nul besoin d'employer un langage jargonneux ("agile", "scrum", etc) : il suffit d'illustrer cette différence en montrant ce que l'on fait différemment.
Cette différence est marquée en particulier dans le manifeste de beta.gouv.fr et peut être reformulée ainsi :
- Nous considérons les besoins des usagers avant ceux des administrations. Les décisions et priorités des équipes sont guidées par les retours des utilisateurs au fil de l'eau, et non par un cahier des charges produit une fois pour toute.
- 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, ces é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.
- 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. 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.
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 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'entresoi.
Ces habitudes de langage, souvent confortables en interne, 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 l'on fait 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
- "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)