Projet numérique ONG : les quatre tests avant de se lancer

Quelle partie de votre dispositif cesse de fonctionner le jour où plus personne ne paie l’abonnement de données, l’hébergement du serveur ou l’intervention du développeur ?

Posez la question à voix haute avant de rédiger. Un projet numérique ONG se distingue des autres par un point précis : l’outil qu’il produit continue de coûter de l’argent après la fin du financement, alors qu’un forage ou une salle de classe n’engendrent qu’un entretien modeste. Les financeurs du secteur ont vu suffisamment de plateformes silencieuses pour instruire ces dossiers avec un œil méfiant. Quatre tests suffisent à séparer un projet utile d’un gadget bien présenté.

Premier test : le problème existait-il avant l’outil

Écrivez en trois phrases le dysfonctionnement que vous voulez corriger, sans employer le moindre terme technique. Aucune application, aucune plateforme, aucun tableau de bord dans ces trois phrases.

Si l’exercice résiste, votre projet part d’une solution en quête d’un usage. Ce cas est fréquent et il se reconnaît à un symptôme : le document décrit longuement les fonctionnalités et brièvement les personnes.

Si l’exercice passe, vérifiez ensuite que la cause du problème se situe bien dans la circulation de l’information. Un agent de terrain qui remplit des fiches papier illisibles a un problème d’outil. Un agent de terrain qui ne se déplace pas parce que sa moto est en panne depuis trois mois a un problème que nulle application ne réglera. Le numérique traite les défauts de circulation, de traçabilité et de délai, et il aggrave tous les autres en ajoutant une couche de complexité.

Ce travail d’identification se conduit avec les outils classiques du montage de projet, notamment la méthode que nous détaillons dans notre article sur l’arbre à problèmes et l’arbre à objectifs.

Deuxième test : ce que le terrain supporte réellement

C’est l’étape que les dossiers rédigés depuis un bureau climatisé sautent systématiquement. Elle se mène sur place, carnet en main, dans la zone d’intervention et non dans le chef lieu.

Vérifiez la couverture réseau là où l’outil servira, pas au bord de la route bitumée. Notez si la connexion tient debout en milieu de journée, si elle permet d’envoyer une photo, si elle tombe en saison des pluies. Un outil qui exige une connexion permanente devient inutilisable sur une bonne partie du territoire d’intervention.

Regardez les terminaux. Quel téléphone possèdent réellement les personnes concernées, quelle taille d’écran, quelle capacité de stockage, quel âge. Une application qui pèse lourd ne s’installe pas sur un appareil déjà saturé, et son propriétaire la supprimera au premier manque de place.

Comptez le coût de l’usage. Chaque envoi de données, chaque message, chaque synchronisation consomme un forfait que quelqu’un paie. Un agent communautaire non salarié qui doit financer sa propre connexion pour remplir vos formulaires cesse de les remplir. Chiffrez cette dépense et inscrivez la au budget, mois par mois.

Regardez l’électricité. Un centre qui subit des coupures quotidiennes a besoin d’une solution de charge, et cette solution a un prix.

Regardez enfin la langue et la lecture. Une interface en français écrit exclut une partie des utilisateurs visés. Les réponses existent : pictogrammes, saisie vocale, message vocal préenregistré, formulaires très courts. Elles se décident au moment de la conception et elles coûtent cher à rattraper après.

Pour la collecte de données de terrain, des solutions éprouvées existent déjà et évitent de financer un développement spécifique, comme nous l’expliquons dans notre page consacrée à la collecte de données terrain avec KoboToolbox.

Troisième test : qui paie l’année deux et l’année trois

Voici le calcul que fait l’instructeur et que la plupart des porteurs oublient.

Un outil numérique génère des dépenses récurrentes : hébergement, nom de domaine, envoi de messages, licences, mises à jour de sécurité, corrections de bugs, adaptation aux nouvelles versions des systèmes d’exploitation, et surtout du temps humain pour répondre aux utilisateurs. Un outil qui n’est pas mis à jour pendant deux ans devient inutilisable, indépendamment de sa qualité initiale.

Établissez un tableau du coût annuel de fonctionnement, pour les trois années suivant la fin du projet, et dites qui paie chaque ligne. Les réponses honnêtes sont peu nombreuses : une organisation qui inscrit la dépense à son budget de fonctionnement, une institution publique ou une commune qui reprend l’outil par convention, des utilisateurs qui contribuent, ou une activité économique adossée à l’outil.

Prenons un exemple entièrement fictif, donné pour illustrer la proportion. Un projet consacre l’essentiel de son enveloppe au développement d’une plateforme, un peu à la formation des utilisateurs, et rien à son fonctionnement après la clôture. Le lecteur professionnel en déduit que l’outil s’arrêtera dans l’année qui suit, et il a raison.

Une alternative sérieuse existe et mérite d’être examinée avant tout développement : assembler des outils existants plutôt que d’en créer un. Notre article sur le choix d’outils numériques sans se ruiner recense les questions à poser avant d’ouvrir un chantier de développement, et celui consacré à la digitalisation d’une petite organisation indique par quel bout commencer.

Quatrième test : à qui appartiennent le code et les données

Un projet numérique produit deux actifs et beaucoup de dossiers ne disent rien de leur sort.

Le code source, d’abord. Précisez par écrit, dans le contrat de développement, qui en détient les droits, où il est déposé, et sous quelle licence il pourra être réutilisé. Un prestataire qui garde le code et disparaît laisse une organisation propriétaire d’une application qu’elle ne peut plus faire évoluer. Exigez la remise du code et des accès administrateurs comme condition du paiement du solde, avec une procédure de recette écrite.

Les données ensuite, en particulier quand elles concernent des personnes. Un projet qui collecte des informations sur des bénéficiaires assume une responsabilité qui survit au projet lui même : finalité de la collecte, consentement des personnes, durée de conservation, sécurisation des accès, suppression en fin de cycle. Ces obligations se traitent dès la conception, et notre page sur la sécurisation des données de bénéficiaires en détaille les mécanismes concrets.

Traitez enfin la question de l’intelligence artificielle avec la même prudence si votre projet en prévoit l’usage. Les cas d’emploi réalistes dans une organisation de taille modeste sont recensés dans notre article sur l’usage de l’intelligence artificielle dans une ONG, et ils demandent les mêmes garanties sur les données que n’importe quel autre traitement.

Les cas où le canal le plus simple l’emporte

Un dossier gagne en crédibilité quand il montre que le porteur a envisagé des solutions plus légères et explique pourquoi il ne les a pas retenues.

Le message texte ordinaire fonctionne sur tous les téléphones, sans installation et sans connexion internet. Le message vocal contourne la barrière de la lecture. Un groupe de messagerie déjà utilisé par les intéressés a un taux d’adoption que nulle application nouvelle n’atteindra. La radio locale touche des zones qu’aucune plateforme ne couvre. Un registre papier bien conçu, saisi une fois par semaine, produit des données parfaitement exploitables.

Comparez systématiquement votre solution à ces canaux, en coût par personne touchée et en probabilité d’usage réel. Quand le numérique gagne, votre dossier le démontre. Quand il perd, vous avez économisé une somme importante et beaucoup de frustration.

Le chronogramme qui condamne un outil avant sa naissance

Une erreur revient dans presque tous les dossiers de ce type : l’outil est livré au dernier trimestre du projet, juste avant la clôture.

Personne n’aura le temps de l’utiliser en conditions réelles, de remonter les défauts, de corriger, de former les utilisateurs, ni de constater ce qui fonctionne. L’évaluation finale portera sur un logiciel neuf que personne n’a encore ouvert.

Renversez la séquence. Livrez une version sommaire tôt, même incomplète, testez la avec un petit groupe pendant plusieurs mois, corrigez, puis déployez. Prévoyez explicitement au chronogramme une phase de test, une phase de correction et une phase d’appropriation. Prévoyez aussi le scénario d’échec technique dans votre analyse, selon la logique décrite dans notre article sur le plan de gestion des risques d’un projet.

Ce que l’instructeur cherche en trois minutes

Il regarde la part du budget consacrée au développement par rapport à celle consacrée à l’accompagnement des utilisateurs. Il cherche une ligne de fonctionnement après la clôture. Il cherche la trace d’un test terrain avant l’écriture. Il cherche le nom de la personne qui administrera l’outil au quotidien, et le temps de travail associé.

Un dossier qui répond à ces quatre points se lit comme un projet conduit par des gens qui ont déjà vu un outil mourir faute de maintenance. C’est exactement le signal recherché.

Testons votre idée avant d’engager un développement

Venez avec le problème que vous voulez traiter, le public concerné et ce que vous savez de ses conditions d’accès au réseau. En une séance de travail, nous passons les quatre tests, nous chiffrons le coût de fonctionnement sur trois ans et nous comparons votre solution aux canaux plus simples. La rédaction du document de projet relève de notre prestation de formulation de projet. Écrivez à contact@nassika-business.com ou appelez le +229 01 96 16 36 65 pour fixer la date.