A première vue, réussir la construction d’un système d’information (SI) semble simple, et même beaucoup plus simple que de réussir les systèmes complexes que nous, ingénieurs militaires, avons l’habitude de concevoir. En effet, il est beaucoup plus facile de modifier un SI une fois construit pour en corriger les défauts que les systèmes basés sur du matériel. Mais pour autant, l’État est régulièrement obligé de stopper la construction de gros SI, sur le constat d’un échec de leur construction, et ce après avoir dépensé des dizaines de millions d’euros en pure perte.

Après avoir analysé et compris les raisons des échecs de ces nombreux systèmes, je me suis demandé si les méthodes de construction de nos SI sont bien les bonnes. Ne seraient-elles pas devenues obsolètes ? 

J’ai alors découvert la méthode produit, et je suis maintenant convaincu qu’elle est beaucoup plus adaptée pour réussir la construction des systèmes d’information. Cette méthode, initiée par les GAFAM, est utilisée avec succès depuis maintenant 10 ans par l’État britannique, et par de nombreux groupes privés français.

Leur approche est radicalement différente de la construction des SI en cycle en V, et repose sur des principes simples à mettre en œuvre, dont les plus emblématiques sont les suivants :

-  Mise au centre de l’utilisateur du produit : l’équipe produit est focalisée sur la performance de son produit vu de ses utilisateurs, et cherche par tout moyen à collecter le feedback de l’utilisateur pour s’assurer qu’il est satisfait. 

-  Pas d’effet tunnel : l’équipe produit confronte très régulièrement ce qu’elle a construit à des usages et des utilisateurs, et s’assure ainsi que ce qui est construit répond au besoin. Pour cela, elle met en œuvre une approche de mise en production progressive de son système d’information avec un premier produit minimum viable disponible en quelques mois.

-  Pas de grosses équipes : une équipe produit ne doit pas excéder 10 personnes, de manière à limiter le nombre d’interactions à gérer ; si le projet est plus gros, alors il est divisé en plusieurs équipes produits, avec des interfaces les plus lâches possibles entre produits.

-  Une mise en œuvre de standards techniques communs à tous les produits d’un périmètre et une formation à ces standards.

-  Des moyens proportionnés au succès du produit : frugalité de moyens au démarrage, augmentation des moyens si le produit rencontre ses utilisateurs. Un droit à l’échec dans les premières phases du produit.

-  Un management par la métrique : l’équipe produit est autonome dans sa prise de décision (une vraie révolution pour l’administration française), et reporte à travers des indicateurs pertinents pour relater l’avancée du produit.

La petite équipe produit, pour faire un gros système d’information, s’appuie sur d’autres produits, se focalisant sur sa plus-value, sans devoir refaire ce que d’autres ont déjà fait. Le cloud se distingue de l’hébergement traditionnel car c’est justement à ce problème qu’il s’applique : comment faciliter la vie de l’équipe produit en lui proposant tous les services managés (et donc qu’elle n’a plus besoin de gérer, juste de configurer) dont elle a besoin pour être efficace. Et ça marche… quand on a la chance de pouvoir utiliser un cloud de qualité, comme les clouds d’hyperscalers américain. 

« LA MÉTHODE PRODUIT EST BEAUCOUP PLUS ADAPTÉE »

Dans cette mutation vers le mode produit, l’État français en est aux prémices : des projets ont appliqué avec succès ce mode de production, mais nous sommes très loin de la généralisation, telle qu’impulsée dans la stratégie «cloud au centre», qui s’impose aux administrations de l’État selon les termes de la circulaire du 5 juillet 2021. 

Pour réaliser cette mutation, l’État devra relever 3 défis :

-  Le défi culturel : l’approche pour construire les SI est très différente d’auparavant, et nécessite un changement culturel profond des équipes de développement et une formation aux nouvelles compétences nécessaires. Il faut également revoir les méthodes de management, le rôle de la hiérarchie et donner plus d’autonomie aux équipes produits.

-  Le défi organisationnel : nous devons revoir les méthodes et l’organisation de la production des SI, avec d’un côté des équipes d’infrastructures qui construisent les produits utilisés par tous, et de l’autre des équipes produits intégrés dans les métiers. Il faut également revoir la manière d’acheter les prestations informatiques où l’on achète de la consommation de services managés gérés par des tiers et des membres d’une équipe produit plutôt qu’une prestation globale forfaitaire. 

-  Le défi de la mutualisation : pour des questions de sécurité et de souveraineté nationale, pour de nombreux systèmes il n’est pas envisageable de consommer des offres externes à l’État. L’exemple du privé nous montre que pour construire une offre de cloud interne de qualité, il faut une équipe de 150 personnes au moins, équipe impossible à réunir dans chaque ministère. Il est donc urgent de construire une offre interne de qualité, et d’inciter les ministères à la consommer, afin d’atteindre la taille critique qui justifie l’investissement. 

Améliorer l’efficacité de l’État en dotant ses métiers de systèmes d’information pertinents et performants est possible, avec la généralisation de la méthode produit et de l’usage du cloud. Osons donc nous orienter vers cette voie prometteuse.