Comprendre nos difficultés et partager nos apprentissages
Le programme Entrepreneur(e)s d’Intérêt Général ouvre l’administration à des data scientists, designers, développeuses et développeurs recrutés pour relever des défis d’amélioration du service public à l’aide du numérique et des données. En tant qu’entrepreneur(e)s d’intérêt général nous avons 10 mois pour résoudre un défi avec nos mentors et nos différentes parties prenantes.
Pour que tous les défis réussissent, le programme a mis en place différents temps de partage et de production. En septembre, nous avons ainsi tous participé à un séminaire qui nous a permis de faire le point sur les mois écoulés et d’envisager la suite des défis.
Tout comme la promotion des EIG 2, nous avons passé deux jours à l’Hermitage, un tiers-lieu d’innovations rurales et citoyennes pour faire la rétrospective de 7 mois de travail et imaginer la suite. Dans un effort de remise en question, nous avons organisé un failcon, un atelier sur les difficultés que nous avons rencontrées dans nos défis, et ébauché des pistes pour les dépasser. Nous vous en livrons les conclusions, en espérant que cela aide les équipes des prochaines promotions à mener leurs barques.
Début de journée pour la répartition en ateliers
Identifier nos difficultés pour les surpasser
Un tour de table nous a permis d’identifier les difficultés que nous avions rencontrées et d’en tirer quelques apprentissages, possiblement utiles aux professionnel(le)s du numérique de l’administration publique :
-
Identifier la gouvernance et les donneurs d’ordres. La gouvernance d’un projet n’est pas toujours simple à comprendre, surtout lorsque le projet répond à de nombreuses exigences métiers. De plus, dans l’administration, un projet se situe souvent dans une organisation multipartite, ce qui rend la prise de décision et la circulation de l’information particulièrement complexes.
Une première réponse consiste à bien s’appuyer sur les mentors, opérationnel et stratégique, pour prendre des décisions qui permettent au projet d’avancer et d’être pérennisés.
Une deuxième réponse est de bien communiquer avec toutes ses parties prenantes. Le défi Cartobio a partagé le constat d’une complexité institutionnelle : le défi est porté par l’Agence BIO (Agence française pour le développement et la promotion de l’agriculture biologique), un établissement sous double tutelle à la fois du ministère de l’Agriculture et de l’alimentation et du ministère de la Transition écologique et solidaire. Pour réaliser le défi, l’équipe travaille avec l’INAO (Institut national de l’origine et de la qualité) et les organismes certificateurs (des entreprises privées qui assurent la certification et le contrôle du respect d’un cahier des charges par des opérateurs bio), pour cartographier l’agriculture bio en France et alléger les contraintes administratives auprès des agriculteurs et des opérateurs bio. L’équipe a donc multiplié les interactions, tout en partageant régulièrement le déroulement et les avancées du projet sur une plateforme accessible à tous. Résultat : le défi à réussi à redéfinir les échanges de données entre ces différents acteurs.
-
(Re)cadrer ou faire pivoter son défi pour mieux réussir. Pour qu’un projet avance, la solution doit s’inscrire dans un principe de réalité. Lorsque nous progressons dans notre défi, nous découvrons l’envergure du périmètre, les contraintes, les objectifs, les risques, les délais du projet…
Il faut alors prendre sur soi de proposer une solution qui fasse le compromis entre la faisabilité technique et le bénéfice opérationnel, voire stratégique, du livrable. Par exemple, au sein de l’Arcep, le défi DataReg devait développer un “datawarehouse” pour permettre la bonne circulation des données. Les EIG ont identifié que pour obtenir une solution viable, des pré-requis techniques étaient nécessaires. Ils ont donc mis en place un ETL (Extract, Transform, Load) pour répondre aux besoins des métiers en prévision du développement du “datawarehouse”.
-
Prendre le temps de décider de la solution. Le début d’un défi est dédié à la compréhension du sujet et des enjeux techniques : on prend connaissance de l’environnement technique, on vérifie la problématique auprès des utilisateur, on fait des benchmarks… Ce temps peut être considéré par l’administration comme long, peu productif et difficilement communicable, mais il est nécessaire.
Par exemple, l’équipe Plume, qui développe un outil de rédaction collaborative pour la Cour des comptes, a mis plusieurs semaines à décider de s’appuyer sur une solution open-source nommée Editoria. In fine, cette solution a permis au défi de bénéficier de ressources humaines supplémentaires, d’avoir des fonctionnalités plus avancées, mais surtout de garantir la pérennisation du projet à travers ce partenariat.
-
Faire de la DSI son alliée. Une DSI ne peut pas autoriser tous les langages informatiques, notamment pour la stabilité et la maintenance de ses outils. Notre rôle est donc de trouver notre place entre l’innovation numérique et l’exploitation des outils existants.
Pour la maintenabilité de notre production, nous devons à la fois négocier et argumenter avec la DSI sur les gains de la stack technologique choisie. En échangeant avec la DSI dès le commencement, le défi Acoss-Plateforme a acté l’utilisation d’un nouveau langage au sein de l’Acoss. L’équipe travaille sur la mise en place d’un simulateur de fin de contrat pour les particuliers employeurs de Pajemploi. En s’appuyant sur une nouvelle technologie (Nebular surcouche d’Angular), ce défi trace donc une nouvelle route, offrant un exemple d’innovation technologique, car il préfigure de la refonte de Pajemploi, et s’inscrit donc dans la transformation numérique de l’Urssaf.
-
Mettre sa production en open-source dès le début du projet. Plus qu’une valeur ou un dogme, l’obligation d’ouvrir son code a été définie dans la loi pour une République Numérique de 2016 (cf. documentation EIG : Publier et réutiliser des codes sources de logiciels). C’est une raison supplémentaire de travailler main dans la main avec sa DSI, et cela avant même le démarrage du projet. De plus, nous parlons bien ici de “production” et pas uniquement de code, car les productions des designers sont tout aussi importantes à ouvrir : pour comprendre la méthodologie, mais aussi pour réutiliser les éléments ergonomiques et graphiques, dans l’industrialisation des services et des produits au sein d’une administration (cf. documentation EIG : Ouvrir son design).
Le projet CibNav nous a fait part du fait qu’il était plus simple d’être dans une politique de l’ouverture par défaut avant d’être enlisé dans des contraintes internes pour arriver à ses fins. In fine, le code de leur solution RapportNav a été publié sur le GitHub des ministères de la Transition écologique et solidaire & de la Cohésion des territoires.
Petit message d'Adnène Trojette aux EIG en fin de séminaire
“Après 10 mois, le défi ne fait que commencer”, un EIG
En tant qu’EIG, nous nous positionnons sur une ligne de crête entre produire et innover. Cette ligne est intéressante à suivre lorsque l’on a une vision opérationnelle et une perspective du projet à long terme. Nos travaux deviennent d’autant plus motivants lorsque nous obtenons un compromis entre la faisabilité technique, la qualité du livrable produit, le temps de production et le bénéfice de la solution choisie. Malheureusement, il nous arrive de constater que notre travail peut-être ralenti lorsque la mesure du risque prime sur la mesure du bénéfice d’impact.
Pour conclure nous partageons le fait qu’innover c’est transformer et dépasser les difficultés grâce aux apprentissages que nous avons listées : les défis EIG servent à prototyper une réalisation et des méthodes. Ils servent aussi à les industrialiser dans l’administration. Ayant compris la complexité de notre environnement - les différents points de vue, problématiques, contextes et domaines de compétences - nous pouvons innover intelligemment. Ainsi, portés comme exemples au sein de nos administrations, les défis EIG permettent de prouver qu’une transformation est possible, sans doute l’un des meilleurs moyens de convaincre, et peut-être même le seul.