Nos vues

Les systèmes d'information gouvernementaux ne tombent pas en panne parce que la technologie est « trop difficile ». Ils échouent parce que le problème n'est pas défini, que les utilisateurs ne sont pas compris et que les décisions sont retardées jusqu'à ce que le projet devienne une cible mouvante. Une période de planification de 90 jours impose de la discipline : vous n'avez pas le temps d'atteindre la perfection. Vous avez besoin de choix clairs, d'une portée réaliste et d'un plan réalisable.

Cet article présente une feuille de route minimale viable : le plus petit ensemble d'étapes et de résultats qui rendent un système d'information gouvernemental bancable, achetable et réalisable, sans noyer les équipes dans la paperasserie.

Ce que signifie réellement « feuille de route minimale viable »

Une feuille de route n'est pas un diaporama contenant des aspirations. C'est un outil de décision.

En 90 jours, votre objectif est de produire juste assez de clarté pour que la direction puisse approuver l'orientation, que les responsables du budget puissent voir les facteurs de coûts, que le service informatique puisse valider la faisabilité et que le service des achats puisse lancer un appel d'offres crédible. Si vos résultats ne peuvent pas être utilisés pour prendre des décisions, il ne s'agit pas de résultats de feuille de route, mais de documentation.

Le critère de référence est simple : au 90e jour, vous devriez être en mesure de répondre, en langage clair, à ce que nous construisons, à qui il est destiné, comment cela fonctionnera, combien cela coûtera, comment nous allons le réaliser et comment nous allons mesurer le succès.

La structure de 90 jours (sans les peluches)

Imaginez le travail en quatre sprints. Chaque sprint se termine par des résultats concrets qui réduisent les risques.

Jours 1 à 10 : Harmoniser l'objectif et l'autorité

Commencez par définir le « pourquoi » et le « qui décide ». C'est là que de nombreux projets échouent discrètement : cinq agences partagent le même système, mais personne n'est propriétaire des décisions.

Vous voulez une courte charte de projet qui nomme le sponsor, le responsable du produit, le modèle de gouvernance et la cadence de décision. Associez cela à un énoncé précis du problème (ce qui est cassé aujourd'hui, pour qui et à quel prix). Si vous ne pouvez pas l'écrire sur une demi-page, c'est que vous n'êtes pas prêt à concevoir quoi que ce soit.

Jours 11 à 30 : Découvrez les utilisateurs, les processus et les contraintes

Ce sprint est une question de réalité. Vous cartographiez le service tel qu'il existe : parcours des utilisateurs, étapes du processus, goulots d'étranglement et problèmes liés aux données. L'objectif n'est pas de tout documenter, mais d'identifier les quelques moments qui sont à l'origine de 80 % des retards, des plaintes ou des fuites.

À la fin de ce sprint, vous devriez disposer de parcours utilisateur validés, d'une liste restreinte de cas d'utilisation prioritaires et d'une vision claire des contraintes qui façonneront la solution : obligations légales, protection des données, limites de connectivité, systèmes existants et capacité opérationnelle.

Jours 31 à 60 : Concevoir le « système minimum viable »

Maintenant, vous traduisez les besoins en quelque chose de constructible. Le changement le plus important à cet égard est la discipline : votre système doit fournir un service minimum viable, et non toutes les fonctionnalités souhaitées par toutes les parties prenantes.

C'est ici que vous définissez les exigences fonctionnelles de manière à ce que les achats et les fournisseurs puissent fixer les prix, tout en laissant de la place pour les itérations. Vous décidez également très tôt si vous allez créer, acheter ou configurer, et quelles intégrations ne sont pas négociables. Un schéma d'architecture simple qui montre les flux de données et la propriété est souvent plus utile que 40 pages de texte.

D'ici le 60e jour, vous devez disposer d'un projet de plan de solution : portée, modules, rôles, aperçu du modèle de données, besoins d'intégration, approche en matière de sécurité et modèle opérationnel réaliste pour l'institution qui le gérera.

Jours 61 à 90 : Transformez le plan en quelque chose qui peut être financé et acheté

C'est là que les feuilles de route deviennent réalité. Vous convertissez le plan directeur en plan de livraison : séquencement, ressources, coûts, stratégie d'approvisionnement et gouvernance de mise en œuvre.

Surtout, vous définissez ce que signifie « terminé ». Si vous ne pouvez pas mesurer l'adoption et la qualité du service, vous finirez par ne mesurer que des résultats tels que le « nombre de formations dispensées ». Votre package Day-90 doit inclure des indicateurs de performance clés, une approche de surveillance et un plan de gestion du changement qui considère l'adoption comme une caractéristique du produit, et non comme une question secondaire.

Les livrables les plus importants (et pourquoi)

Une feuille de route de 90 jours ne nécessite pas des centaines de pages, mais elle nécessite quelques artefacts puissants :

1) Un descriptif de service d'une page.
Ce que le système va faire, pour qui et la valeur qu'il débloque. C'est ce dont se souviennent et répètent les hauts fonctionnaires.

2) Une liste des « 10 meilleurs » cas d'utilisation avec des critères d'acceptation.
Si le système ne peut pas fournir ces cas d'utilisation de manière fiable, il ne s'agit pas du bon système.

3) Une note sur les données et l'interopérabilité.
Quels ensembles de données existent, lesquels n'existent pas, qui en est propriétaire et lesquels doivent être intégrés à quoi. Cela permet d'éviter des surprises coûteuses par la suite.

4) Une base de référence en matière de sécurité et de confidentialité.
Il ne s'agit pas d'un audit complet, mais de normes minimales claires : contrôle d'accès, journalisation, réponse aux incidents, exigences d'hébergement et contraintes de conformité.

5) Une feuille de route de livraison avec les coûts et l'itinéraire d'approvisionnement.
Phasage, hypothèses en matière de personnel, fourchettes CAPEX/OPEX et ce qui peut être contracté maintenant par rapport à plus tard.

Ces résultats créent de la bancabilité car ils réduisent l'incertitude, principale raison pour laquelle les achats publics de technologies de l'information attirent de faibles offres ou des prix gonflés.

Pièges courants (et comment les éviter)

Piège 1 : essayer de numériser le chaos.
Si le processus sous-jacent est interrompu, sa numérisation ne fait qu'accélérer la défaillance. Au cours de la période de 90 jours, concentrez-vous sur « l'amélioration minimale viable des processus » pour résoudre les problèmes les plus importants.

Piège 2 : Traiter la consultation des parties prenantes comme un moyen de parvenir à un consensus
Il n'est pas nécessaire que tout le monde soit d'accord, il faut que tout le monde soit entendu et qu'il y ait une autorité claire pour prendre des décisions. La gouvernance est l'épine dorsale du produit.

Piège 3 : Ignorer le modèle de fonctionnement.
Un système sans véritable propriétaire, sans ligne budgétaire, sans capacité de support et sans gestion des données est un projet pilote qui ne peut jamais évoluer. Définissez rapidement le domicile institutionnel.

Piège 4 : exigences en matière de rédaction, aucun fournisseur ne peut fixer de prix.
Évitez les termes vagues tels que « moderne, robuste, convivial ». Traduisez-le en exigences mesurables : temps de réponse, temps de disponibilité, normes d'accessibilité, journaux d'audit, rôles des utilisateurs, besoins en matière de rapports.

À quoi cela ressemble en pratique : une note tirée de l'expérience d'Aninver

L'ensemble de nos missions liées au numérique et au secteur public, qu'il s'agisse de la maintenance de la plateforme Web CPIA de la Banque africaine de développement, de la conception de programmes de formation numérique et de renforcement des capacités dans les Caraïbes, ou du soutien aux institutions publiques au moyen de plateformes Web et d'outils de communication numériques, le schéma est constant : les projets avancent plus vite lorsque les équipes s'engagent à respecter une portée minimale viable, une gouvernance claire et des données utilisables dès le premier jour.

Si votre institution planifie un système d'information et souhaite une feuille de route qui puisse réellement être achetée et mise en œuvre, découvrez les travaux d'Aninver et ses articles sur la transformation numérique et la prestation dans le secteur public, où nous partageons des approches pratiques, des leçons apprises et des outils qui aident les projets à passer de l'intention à l'exécution.