Les Questions du Conseil d’Administration Avant d’Approuver un Système Numérique

Un prestataire arrive en réunion du conseil avec une proposition soignée : un tableau de bord, une démonstration, la promesse qu'un nouveau système va moderniser l'organisation. Le conseil n'est pas technique. Le budget, lui, est bien réel. Et la pression de paraître décisif l'est tout autant.

C'est exactement le moment où une routine de gouvernance compte plus que l'expertise technique. Un conseil n'a pas besoin de comprendre le schéma de la base de données. Il a besoin d'une grille de questions courte et répétable, qui sépare un système prêt pour l'approbation d'un système qui ne l'est pas — et de la discipline de poser ces questions même quand une présentation assurée, ou un business case généré par l'IA avec assurance, les rend inutiles en apparence.

Les questions ci-dessous sont regroupées comme un conseil examine réellement une décision : ce qui change, qui porte le risque, ce qui doit exister avant une signature, et quelle règle tranche la décision.

1. Demandez ce qui change réellement — pour tout le monde, pas seulement les utilisateurs évidents

Avant tout chiffre, le conseil doit pouvoir répondre à une question en une phrase : quelle décision ou quel service précis ce système améliore-t-il ? « Moderniser » n'est pas une réponse. « Gagner en efficacité » non plus. Une réponse utile nomme un résultat concret — le système trie les demandes de crédit, détecte des schémas de fraude, réduit la file d'attente d'une agence précise à Dakar ou à Abidjan, ou donne au personnel de première ligne une information qu'il doit aujourd'hui demander par téléphone.

Demandez ensuite quels utilisateurs changeront réellement leur façon de travailler au quotidien. Un système peut impressionner lors d'une démonstration et laisser les personnes qui en dépendent faire le même contournement manuel qu'avant, simplement redirigé vers un nouvel écran.

Posez enfin la question que les conseils omettent le plus souvent : quel est l'effet sur les personnes qui n'utiliseront pas le système tous les jours ? Les utilisateurs occasionnels — un responsable d'agence qui consulte un rapport une fois par mois, un agent de terrain à Douala ou à Kinshasa qui saisit des données une fois par semaine, un administrateur qui examine un extrait trimestriel — apparaissent rarement dans une démonstration de fournisseur. Si le système leur est peu pratique, ils construiront un contournement. Les contournements des utilisateurs occasionnels sont l'une des façons les plus discrètes dont un investissement approuvé échoue, car personne ne signale le problème : chacun le contourne en silence.

2. Demandez qui possède les données, ce qui se passe en cas de panne, et comment vous partez

Trois questions vont ensemble, car les fournisseurs y répondent rarement avec sincérité de leur propre initiative.

Qui détient légalement la propriété des données ? Établissez par écrit que l'organisation — et non le fournisseur — possède les entrées, les sorties, et le droit de les auditer. « Le fournisseur les stocke en sécurité » n'équivaut pas à « l'organisation les possède et peut les extraire sur demande ».

Que se passe-t-il lors d'une panne de connexion ou de système ? Chaque proposition doit inclure une réponse de continuité d'activité pour le moment hors ligne : l'agence sans connexion internet, le jour où le service cloud du fournisseur devient inaccessible, la semaine où le réseau mobile tombe. Si la réponse est un silence, considérez que le service s'arrête avec la connexion.

Quelle est la stratégie de sortie ? Avant de signer, le conseil doit savoir précisément comment l'organisation pourra quitter ce fournisseur si nécessaire — sans perdre l'accès à ses données, et sans dépendance opérationnelle (lock-in) qui rendrait l'option du « non » inabordable plus tard. Un système sans stratégie de sortie décrite est un système que le conseil approuve de façon permanente, que ce mot figure ou non dans le contrat.

3. Exigez ces éléments avant toute signature

Traitez ce qui suit comme un filtre de gouvernance, pas une liste de souhaits. Si l'un de ces éléments manque, la proposition n'est pas prête pour l'approbation — elle est prête pour un travail complémentaire.

Aucun de ces cinq éléments n'est technique. Un conseil incapable d'évaluer un schéma d'architecture peut tout à fait vérifier si un responsable est nommé, si une ligne budgétaire existe, et si une date de revue figure au calendrier. C'est précisément à ce niveau que doit s'exercer la surveillance du conseil.

4. Approuvez l'étape contrôlée, pas la grande promesse

Voici la règle qui tranche la plupart des désaccords au sein d'un conseil : n'approuvez jamais un déploiement total sur la base de preuves limitées. Autorisez à la place un pilote contrôlé et limité dans le temps, rattaché à un résultat vérifiable — un groupe d'utilisateurs défini, une période définie, et une mesure de réussite définie.

Engagez-vous ensuite, dans la même réunion, sur la suite selon chaque issue possible :

• Si le pilote réussit avec des preuves réelles, étendez le déploiement à la phase suivante.
• Si le pilote échoue, ou ne produit aucune preuve exploitable, arrêtez et corrigez le problème de données ou de processus sous-jacent avant d'engager davantage de dépenses.

Cette règle unique protège le conseil des deux échecs les plus coûteux : approuver une « grande promesse » jamais testée, et continuer à financer un système au-delà du moment où les preuves indiquaient déjà d'arrêter.

Un mot sur les business cases générés par l'IA

Les outils d'IA générative peuvent rédiger un business case, modéliser des scénarios et résumer la proposition d'un fournisseur plus vite qu'une équipe humaine ne le ferait à la main. C'est un travail de préparation utile. Ce n'est pas une preuve, et un conseil ne doit jamais le traiter comme une démonstration indépendante que le système tiendra ses promesses.

Un document assisté par l'IA a besoin des mêmes vérifications qu'un document rédigé par une personne : des chiffres vérifiés, un responsable nommé prêt à répondre de ces chiffres, et un pilote ayant produit des résultats réels et vérifiables. Si personne dans le dossier ne peut expliquer d'où vient une projection, cette projection n'est pas une preuve — quelle que soit la fluidité du texte. L'IA recommande le contexte ; l'humain décide. L'outil ne décide pas, et il ne répond pas du résultat devant le conseil.

Le test en une page avant la fin de la réunion

Avant de clore ce point de l'ordre du jour, la présidence doit pouvoir répondre à voix haute à six questions, sans consulter le diaporama :

1. Quelle décision ou quel service précis ce système améliore-t-il, et comment saurons-nous s'il a fonctionné ?
2. Qui sont tous les utilisateurs concernés, y compris ceux qui touchent rarement le système ?
3. Qui détient légalement les données, et que devient le service pendant une panne ?
4. Quelle est notre voie de sortie si la relation avec ce fournisseur doit prendre fin ?
5. Avons-nous un responsable nommé, un budget réel, un temps de formation protégé, une voie de support, un registre des risques et une date de revue ?
6. Approuvons-nous une première étape contrôlée avec un résultat mesurable, ou une promesse sans preuve derrière elle ?

Si les réponses sont claires, approuvez le pilote et inscrivez la date de revue à l'agenda avant que quiconque ne quitte la salle. Si elles ne le sont pas, la décision honnête du conseil n'est pas « non » — c'est « pas encore, tant que ces manques ne sont pas comblés ».