Pourquoi 43 % des pilotes d'IA gouvernementaux ne passent jamais à l'échelle

01Un pilote qui fonctionne ne prouve pas que la technologie fonctionne

L'enquête 2025 de l'OCDE sur l'usage de l'IA par les gouvernements a constaté que 43 % des déploiements restent bloqués au stade du pilote. Ce chiffre n'est pas un instantané d'une technologie encore en maturation. C'est la mesure d'institutions qui ont construit quelque chose, l'ont vu fonctionner dans un environnement contrôlé, puis ont échoué à le porter en production.

Les environnements de pilote disposent de données sélectionnées, d'un soutien dédié du prestataire et de délais indulgents. La production, elle, impose des exigences d'audit, des obligations de conformité, des lacunes de connectivité et des citoyens qui attendent que le système soit juste du premier coup. Un pilote prouve qu'un système peut fonctionner lorsqu'il est isolé de la réalité. Il ne prouve pas que l'institution peut le faire tourner une fois cet isolement disparu.

Dans les initiatives numériques du secteur public africain, six modes de défaillance expliquent l'essentiel de l'écart entre le pilote et la production. Aucun d'eux n'est principalement technique.

021. La pensée technologique d'abord

La plupart des initiatives numériques commencent par un appel d'offres qui précise la capacité de serveurs et les fonctionnalités du tableau de bord. Il précise rarement qui utilisera le livrable, pour quelles décisions, ou selon quelle norme de preuve. Quand l'outil est le point de départ au lieu du problème institutionnel, le système qui en résulte s'optimise pour le jour de la démonstration, pas pour la décision qu'il était censé soutenir.

032. L'ambiguïté de propriété

L'informatique possède les serveurs. Les opérations possèdent le processus. La politique possède le mandat. Dans la plupart des pilotes, aucune entité unique ne possède les preuves que le système produit. Et quand le financement expire, la responsabilité s'évapore avec lui. Un système sur lequel trois services ont laissé leur empreinte et qui n'a pas de propriétaire nommé ne survit pas à sa première transition de direction.

043. Les lacunes de preuve

Un tableau de bord n'est pas une preuve. Une preuve a une traçabilité : elle peut être rattachée, à partir du chiffre affiché à l'écran, à ses données sources, à la méthode utilisée pour les collecter et à chaque transformation appliquée en chemin. Les pilotes produisent fréquemment des tableaux de bord qui paraissent faisant autorité et qui ne peuvent pas répondre à une question d'audit élémentaire : d'où vient ce chiffre, et pouvez-vous montrer votre travail.

054. La dépendance au pilote

Traiter le pilote comme la preuve, plutôt que comme un test, est l'une des erreurs les plus coûteuses de la technologie du secteur public africain. Les conditions indulgentes d'un pilote (données propres, ingénieurs du prestataire disponibles, délais généreux) sont exactement les conditions que la production n'offrira pas. Confondre les deux, c'est budgéter un déploiement qui présuppose des problèmes que le pilote n'a jamais eu à affronter.

065. La gouvernance après le déploiement

Le contrôle d'accès, la classification des données, la politique de conservation et la journalisation d'audit devraient être des contraintes de conception dès le premier schéma d'architecture. Au lieu de cela, elles sont fréquemment rajoutées après la mise en service, une fois que les auditeurs ou les régulateurs posent des questions auxquelles le système n'a jamais été conçu pour répondre. Une gouvernance rajoutée après coup sur un système en production coûte plus cher, couvre moins et arrive après que les décisions qu'elle était censée protéger ont déjà été prises.

076. Le succès sans succession

C'est le mode de défaillance le plus courant dans les environnements financés par les bailleurs, et le plus coûteux. L'équipe du pilote termine son contrat et s'en va. Le tableau de bord reste actif, mais personne dans l'institution ne peut expliquer ce que les chiffres signifient, les valider ou rattacher un livrable à sa source. L'institution se retrouve avec un système qu'elle ne peut pas exploiter : plus pauvre, ayant dépensé budget et crédibilité pour une capacité qu'elle ne peut pas maintenir.

08Le schéma sous-jacent aux six

Chacun de ces modes de défaillance est une défaillance de gouvernance, non une défaillance technologique. Le remède n'est pas un meilleur prestataire ni un budget plus important. Une institution avec un petit budget et des règles de preuve claires surpassera une institution avec un gros budget et aucune. Le remède consiste à établir la propriété, les normes de preuve et les critères de passage à l'échelle avant que le pilote ne commence, et non après qu'il a réussi.

C'est l'argument en faveur de la gouvernance avant l'échelle : construire la capacité institutionnelle de faire confiance à un système, de l'auditer et de le maintenir avant de décider si l'on doit l'étendre.