Trois raisons pour lesquelles les pouvoirs publics doivent s'approprier le développement logiciel

Cet article est rédigé par Benjamin Seibel, directeur de CityLAB Berlin, et Yi Jun Huang, assistant exécutif de CityLAB Berlin.

• Le problème : les marchés publics échouent souvent à fournir des solutions informatiques viables aux administrations.

• Pourquoi c'est important : Dans la plupart des cas, le développement de produits administratifs numériques ne leur permet pas de répondre aux besoins spécifiques des autorités individuelles.

• La solution : les autorités publiques doivent s'adapter aux processus agiles et s'approprier le développement de logiciels.

"Les produits administratifs numériques sont pour la plupart conçus sur mesure en fonction des exigences spécifiques des autorités individuelles - soit en adaptant en profondeur une solution de marché existante, soit en commandant un nouveau développement."

Simple, rapide et sécurisé, c'est ce que la plupart des fournisseurs informatiques promettent lorsqu'ils proposent leurs solutions informatiques du secteur public aux administrations. Cependant, la réalité des projets informatiques dans l'administration publique est souvent bien différente : trop coûteuse, trop longue, trop compliquée. Bien que les administrations investissent souvent des milliards chaque année dans l'achat et le développement d'infrastructures et de logiciels informatiques, les résultats restent souvent médiocres et ont mauvaise réputation. Mais pourquoi c'est comme ça?

Prenons un peu de recul et examinons le processus d'approvisionnement. Les administrations considèrent généralement le logiciel comme un produit pouvant être acheté sur le marché. Ainsi, les pouvoirs publics procèdent de la même manière que lorsqu'ils achètent des produits conventionnels : le service souhaité est décrit de la manière la plus complète possible dans un appel d'offres public, le soumissionnaire le plus économique remporte le marché et livre un résultat un peu plus tard. L'administration elle-même se limite à la passation et à la gestion des contrats mais reste, dans la mesure du possible, à l'écart du développement des produits.

Il peut y avoir des situations où une telle approche pourrait avoir du sens, par exemple lors de l'achat de programmes bureautiques disponibles dans le commerce ou de l'utilisation d'offres de logiciel en tant que service (SaaS), mais soyons réalistes : dans la plupart des cas, il n'existe pas de solution parfaite pour tous les usages. caisses en attente sur une étagère. En d'autres termes, les produits administratifs numériques sont pour la plupart conçus sur mesure en fonction des exigences spécifiques des autorités individuelles - soit en adaptant en profondeur une solution de marché existante, soit en commandant un nouveau développement.

Pourquoi l'agilité est la clé

Cela nous amène à la question de savoir pourquoi les administrations doivent se familiariser avec les principes du développement logiciel agile qui sont depuis longtemps courants ailleurs, assumer davantage la responsabilité de leurs produits numériques et jouer un rôle beaucoup plus actif tout au long du processus de développement.

Premièrement, c'est un principe du développement logiciel agile que les produits numériques ne peuvent pas être décrits de manière exhaustive à l'avance et doivent ensuite seulement être développés. Au lieu de cela, le logiciel est créé dans des cycles itératifs rapprochés au cours desquels un prototype initialement rudimentaire est testé, adapté et affiné étape par étape et en étroite consultation avec les clients et les utilisateurs.

Le principe des marchés publics de produits laisse peu de place à une telle approche exploratoire de la meilleure solution. Il arrive régulièrement que les autorités publiques décrivent méticuleusement à l'avance un produit souhaité (et y consacrent beaucoup de temps et d'efforts), mais que la voie de développement envisagée s'avère alors impraticable après seulement un court laps de temps. Le fait que des circonstances imprévues surviennent au cours du processus extrêmement dynamique de développement de produits numériques peut difficilement être évité. La seule question est de savoir comment les traiter.

Deuxièmement, il est courant dans le développement logiciel agile d'inclure le point de vue du client non seulement au début et à la fin, mais tout au long du processus. Dans les équipes agiles, cette perspective est représentée par le rôle du "product owner" qui décrit les exigences fonctionnelles du produit du point de vue de l'utilisateur, teste les résultats intermédiaires et priorise les objectifs respectifs pour le prochain sprint de développement.

"Dans les processus agiles, l'échec d'une approche précédemment choisie peut être anticipé beaucoup plus tôt, il est donc encore temps de changer de cap."

Savoir et expertise

Étant donné que le propriétaire du produit fait partie intégrante de l'équipe du projet et est en grande partie responsable de la réussite du projet, il est crucial que ce poste soit occupé par une personne employée dans l'administration correspondante. Bien que les connaissances et les méthodes requises pour ce rôle puissent être apprises en cours de route, le propriétaire du produit doit idéalement avoir de l'expérience dans le développement de produits numériques ou au moins avoir une certaine passion pour les applications numériques. La bonne nouvelle est que des connaissances techniques approfondies ne sont pas absolument nécessaires pour le rôle, puisqu'il s'agit de voir le produit à travers les yeux de l'utilisateur. Ce qui est plus important, c'est la volonté fondamentale et la capacité de s'engager dans un travail de projet agile, qui prend du temps mais qui est très rentable.

Troisièmement, si l'administration assume un rôle actif et formateur dans le développement des applications numériques, la perspective change également avec la position : au lieu de considérer le logiciel comme un produit qu'il faut se procurer sur le marché, il apparaît désormais comme le résultat d'un développement processus que les administrations mettent en œuvre et sont responsables d'elles-mêmes, et dans lequel elles peuvent bien sûr toujours s'appuyer sur un soutien externe (par exemple, des services de programmation, UX ou de conception).

En investissant dans des capacités de développement plutôt que dans un produit fini, les employés de l'administration n'ont pas à spécifier à l'avance tous les détails imaginables de l'application souhaitée mais entrent dans un processus de développement avec une équipe de programmeurs pour trouver la meilleure solution possible à un problème dans un délai et un budget donnés.

Risques et récompenses

On peut se demander s'il est risqué de ne pas définir clairement toutes les fonctionnalités du produit à l'avance, mais c'est en fait un moyen de réduire les risques. Dans les processus agiles, l'échec d'une approche précédemment choisie peut être anticipé beaucoup plus tôt, il est donc encore temps de changer de cap. Même un prestataire, une fois choisi, peut théoriquement être remplacé dans le processus si l'administration en tant que propriétaire du produit veille à une documentation transparente du processus et insiste sur l'ouverture des codes sources développés (ce qui devrait être fait de toute façon).

Compte tenu des ressources limitées, l'idée d'une administration qui poursuit activement le développement de produits numériques peut sembler peu réaliste pour certaines autorités. Cependant, lorsqu'il s'agit de numérisation, ce n'est plus l'argent qui manque depuis longtemps dans de nombreux endroits, mais les compétences et les capacités pour utiliser efficacement cet argent. Mais les compétences peuvent être acquises et les capacités peuvent être créées. Cela devrait en valoir la peine, car ce serait un investissement dans l'avenir d'une administration à capacité numérique.

👋 Vous pouvez créer une publication comme celle-ci ! Partagez vos réflexions avec une communauté de fonctionnaires. Apprendre encore plus

(Crédit image : Unsplash)