Le numérique public comme infrastructure
Imaginez une administration conçue pour fonctionner numériquement
Le citoyen n’a pas besoin de savoir quel bureau traite sa demande.
L’entreprise ne transmet pas la même information à quatre institutions dans la même année.
Le fonctionnaire ne pilote pas un processus national depuis un tableur personnel et une boîte mail.
Une demande a un statut. Une approbation porte un nom. Un paiement laisse une trace. Une décision prise en mars peut être expliquée en novembre.
Un ministère publie un appel à propositions le matin, reçoit les dossiers par voie numérique et les évalue sans une seule enveloppe.
Une région propose des services adaptés à sa population, sur le même socle que le ministère dont elle relève.
Et lorsqu’un nouveau service est nécessaire, personne ne repart de zéro.
Ce n’est pas la description d’un logiciel. C’est la description d’une administration conçue autour d’une infrastructure numérique plutôt qu’autour de ses bâtiments.
Cela a déjà été fait
L’Estonie a reconstruit son administration autour d’une infrastructure numérique partagée et de composants réutilisables plutôt que de systèmes isolés. Singapour traite le numérique public comme une capacité nationale, avec des briques communes dans lesquelles ses agences puisent. Les Émirats arabes unis ont fixé des exigences de service pour les démarches administratives, puis construit les plateformes permettant de les tenir.
Ces pays sont très différents. Ce qu’ils partagent est une décision : traiter le socle numérique comme une infrastructure — construite une fois, gouvernée centralement, réutilisée partout — au lieu de commander séparément le système de chaque institution en espérant que l’ensemble communique.
La question que pose cette brochure est simple.
À quoi cela pourrait-il ressembler au Cameroun ?
Une administration n’est pas une organisation
C’est le point que la plupart des logiciels publics manquent.
Un État comprend des ministères, des agences, des directions, des régions, des communes, des établissements publics, des programmes et des services. Des dizaines de milliers d’agents. Des millions de citoyens et d’entreprises.
Ils n’ont pas besoin de la même application. Le ministère chargé de la santé publique, celui des travaux publics et celui de l’administration territoriale ont des missions, des procédures et des obligations réellement différentes. Une commune ne fonctionne pas comme une direction centrale.
La réponse n’est donc pas « tout le monde utilise le même logiciel ». Cette approche échoue, et elle échoue cher, parce qu’elle demande aux institutions de renoncer à leur manière de travailler.
La réponse est :
Une plateforme. Plusieurs ministères. Plusieurs régions. Plusieurs administrations. Des besoins différents.
Des institutions différentes. Des processus différents. Un socle numérique commun.
Chaque institution conserve ses utilisateurs, ses rôles, ses habilitations, ses procédures, ses formulaires, ses enregistrements et ses états. Ce qu’elles partagent, c’est la mécanique en dessous.
Où cela bloque réellement aujourd’hui
Pas du côté de l’ambition. La plupart des institutions savent ce qu’elles veulent numériser.
Cela bloque parce que chaque service numérique est commandé comme un projet distinct. Chacun acquiert sa propre plateforme, invente ses propres comptes utilisateurs, conçoit sa propre logique de validation, construit son propre système de notification et produit ses propres états.
Le résultat est un ensemble d’applications qui ont chacune résolu un problème et ne se parlent pas — chaque nouveau service ajoutant un îlot, une authentification, un prestataire et un jeu d’enregistrements qui redouble le précédent.
Dix ans de cela produisent une dépense considérable et très peu de cumul.
Ce qu’est réellement un processus administratif
Voici l’argument technique, et c’est la raison pour laquelle un socle commun est possible.
Un processus administratif est rarement un simple formulaire.
Il met en jeu des personnes, des rôles et des habilitations. Il comporte des étapes et des validations, souvent par plusieurs acteurs. Il produit des enregistrements consultables des années plus tard. Il déclenche des notifications. Il implique fréquemment des paiements. Et il doit être auditable : qui a fait quoi, quand, et quelle était la valeur antérieure.
Passez du permis de construire à la subvention de recherche, puis à la demande de congé : presque toute cette mécanique est identique. Ce qui change, ce sont les champs, les étapes, les règles et les droits de chacun.
C’est pourquoi un socle est possible. Les parties communes le sont vraiment. Seule la surface est propre à l’institution.
Le socle que fournit FeePrime
FeePrime est une plateforme en fonctionnement, pas un cadre à remplir. Elle exploite déjà, comme mécanique réutilisable :
Des organisations — des institutions distinctes sur une même plateforme, chacune propriétaire de ses données et de ses frontières.
Des utilisateurs, rôles et habilitations — fins, par module et par action : créer et valider sont deux droits distincts.
Des circuits de validation — une modification peut être saisie par une personne et exiger la confirmation d’une autre avant de prendre effet.
Une piste d’audit complète — chaque modification conserve son auteur, sa date et sa valeur précédente. Rien n’est supprimé : les enregistrements sont archivés et restent consultables.
Des enregistrements et formulaires configurables — données structurées, champs définis, contrôles de saisie, traductions.
Notifications, gestion documentaire, opérations et paiements, gestion du personnel et de la paie, stocks et actifs, rendez-vous et réservations, sites et portails publics, et des API pour se connecter aux systèmes existants.
Chacun de ces éléments répond à une question que pose tout service public numérique. Construits une fois, ils cessent d’être la partie coûteuse du service suivant.
Ce qui pourrait être construit dessus
Pour les citoyens — demandes avec un statut consultable, rendez-vous, permis, enregistrements, attestations, dépôt de pièces, notifications et paiements.
Pour les entreprises — immatriculations, licences, autorisations, réponses aux appels d’offres et à propositions, obligations déclaratives, inspections et paiements à l’État.
Pour les fonctionnaires — cette moitié est souvent oubliée. Les agents publics méritent des outils numériques pour faire fonctionner l’administration autant que les citoyens en méritent pour y accéder : dossiers des agents, congés et demandes internes, circuits de service, validations, affectations, paie et communication interne.
Pour les institutions — communiqués, annonces et avis publics ; une véritable présence numérique pour chaque ministère, agence ou commune sur une infrastructure partagée plutôt qu’un site isolé de plus ; des appels à propositions publiés, reçus, évalués et attribués numériquement, avec les traces qui l’établissent.
La paie mérite une mention propre : c’est l’une des plus grandes opérations récurrentes d’un État. FeePrime peut relier dossiers des agents, paie, opérations, validations et reporting institutionnel en une seule chaîne plutôt qu’en quatre systèmes rapprochés à la main.
Pour être clair sur la nature de cette liste : ce sont des usages que la plateforme peut être configurée ou étendue pour prendre en charge. C’est une description de ce qui peut être construit, non l’affirmation que chacun existe déjà comme module public achevé.
Prêt à l’emploi, configurable, extensible
Le numérique public propose habituellement deux mauvaises options : un produit rigide qui impose sa façon de faire, ou un cadre vide qui est en réalité un projet de développement pluriannuel assorti d’une licence.
FeePrime se situe délibérément entre les deux.
Prêt à l’emploi. Une capacité substantielle existe et tourne aujourd’hui. Organisations, habilitations, validations, audit, enregistrements, paiements, portails : rien de tout cela n’est à reconstruire.
Configurable. Un grand nombre de processus propres à une institution peuvent être assemblés à partir de l’existant : définissez les enregistrements, les champs, les rôles, les étapes et les validations, et le processus tourne.
Extensible. Lorsqu’un besoin sort réellement du périmètre, nous le développons — sur un socle qui gère déjà les quatre-vingt-dix pour cent alentour.
Ce troisième point n’est pas une excuse. C’est la proposition.
Vous n’avez pas à attendre la feuille de route d’un éditeur
Tout programme public sérieux rencontre des exigences qu’aucun produit générique n’avait prévues. La réponse habituelle est qu’elles seront étudiées pour une version future.
Parce que FeePrime est construit et maintenu par l’équipe qui le propose, une institution ayant un processus spécifique peut le voir configuré ou développé à partir du socle existant — sans repartir de rien, et sans report.
Ne construisez pas tout à partir de zéro. N’enfermez pas l’administration dans un progiciel rigide. Bâtissez sur une plateforme capable d’évoluer.
Frontières, responsabilité et confiance
Un logiciel public exige une gouvernance plus forte qu’une application d’entreprise, et la différence tient surtout à la preuve.
Les fondations de FeePrime ont été pensées ainsi : des frontières institutionnelles, chaque organisation restant propriétaire de ses données, tout partage étant une décision et non un défaut ; des rôles et habilitations assez fins pour séparer la saisie de la validation ; une validation à deux personnes là où nul ne devrait pouvoir agir seul ; et une piste d’audit qui rend chaque modification imputable et toute suppression impossible — les enregistrements sont archivés, jamais détruits.
Ce sont des propriétés architecturales de la plateforme, et ce sont celles dont une institution publique a besoin pour répondre d’une décision deux ans plus tard.
Nous ne revendiquerons pas de certifications que la plateforme ne détient pas. Posture de sécurité, hébergement, localisation des données et homologation sont des sujets à traiter sérieusement avec vos équipes techniques, et nous préférons cette conversation à un slogan.
Conçu au Cameroun
FeePrime est conçu au Cameroun, par des personnes qui y travaillent.
Cela compte concrètement, pas sentimentalement. L’équipe est dans votre fuseau horaire, joignable, et capable d’être dans la salle. La plateforme traite déjà correctement le FCFA, le mobile money comme moyen de paiement de plein droit, un reporting orienté SYSCOHADA, le français et l’anglais côte à côte, et la connectivité intermittente comme une condition normale plutôt qu’une exception.
Cela signifie aussi que la feuille de route peut répondre au besoin d’une institution camerounaise sans que ce besoin doive d’abord devenir une priorité mondiale pour une entreprise située sur un autre continent.
Conçu ici. Conçu pour une infrastructure sérieuse. Capable de servir des institutions au-delà d’ici.
Le chemin n’est pas un projet unique et gigantesque
Rien de tout cela n’exige de numériser un État d’un coup. Cette approche a un bilan médiocre partout où elle a été tentée.
Commencez par une institution, un service ou un processus — de préférence un processus douloureux, bien compris et délimité.
Prouvez-le en production, avec de vrais utilisateurs et de vrais enregistrements.
Étendez-le au service, puis à l’institution.
Réutilisez le socle pour le service suivant : comptes, habilitations, validations et audit existent déjà, seul le travail spécifique reste.
Connectez les institutions progressivement, la plateforme sous-jacente étant déjà commune.
Chaque étape livre quelque chose d’utilisable. Chaque étape rend la suivante moins coûteuse. Ce cumul est tout l’argument d’un socle face à un portefeuille de projets.
Discutons d’un projet pilote
La bonne étape suivante est un échange sur un processus concret, dans une institution : ce qu’il implique aujourd’hui, ce à quoi il ressemblerait sous forme numérique, et ce qu’il faudrait pour l’exploiter en production.
Nous serons directs sur ce qui existe déjà, ce qui relève du paramétrage et ce qui relève du développement.
L’administration ne devrait pas avoir à construire son avenir numérique une application déconnectée à la fois.
Le prochain service public numérique devrait reposer sur une plateforme déjà capable de faire tourner les processus qui l’entourent.