Dans beaucoup d'ONG et de PME malgaches, le système d'information ne naît pas d'un choix stratégique. Il se construit petit à petit, presque sans qu'on s'en aperçoive : un fichier Excel pour les activités, un autre pour les bénéficiaires, un tableau pour le budget, quelques formulaires KoboToolbox, des rapports Word, des pièces jointes échangées par WhatsApp ou par e-mail, un dossier partagé quelque part dans le cloud. Et bien souvent, une personne qui est la seule à savoir où se trouve réellement « le bon fichier ».
Pendant un temps, cela fonctionne. Puis l'organisation grandit : les projets se multiplient, les équipes changent, les bailleurs demandent davantage de reporting, les données s'accumulent, et plusieurs personnes commencent à travailler sur les mêmes informations. C'est à ce moment que les mêmes questions reviennent, presque toujours dans le même ordre : quelle est la dernière version ? quel chiffre devons-nous utiliser ? pourquoi ce total est-il différent de celui du rapport précédent ? qui a modifié ce fichier ? où sont les données originales ? peut-on encore lui faire confiance ?
À ce stade, le problème vient rarement d'un manque d'outils. Il s'agit, la plupart du temps, d'un problème de système d'information.
Un système d'information n'est pas une collection d'outils
On réduit souvent le système d'information (SI) à sa dimension technique : ordinateurs, logiciels, bases de données, serveurs, tableaux de bord. C'est une vision trop étroite.
Un système d'information est avant tout un ensemble cohérent de personnes, de processus, de données, de technologies et de règles de gouvernance, organisé pour produire, partager et utiliser l'information. Concrètement, il répond à une série de questions très pratiques : qui a besoin de cette information ? de quelle information a-t-on réellement besoin ? comment est-elle collectée, où est-elle stockée, comment sa qualité est-elle contrôlée, qui peut la modifier ou la consulter, comment est-elle analysée, comment circule-t-elle dans l'organisation ?
Et surtout : quelle décision doit-elle permettre de prendre ?
Cette dernière question change tout. Une organisation peut posséder beaucoup de données, plusieurs bases et de très beaux tableaux de bord, sans disposer pour autant d'un système d'information qui fonctionne réellement. La valeur d'un SI ne se mesure pas au nombre d'outils utilisés, mais à sa capacité à transformer une information fiable en action utile.
Cinq signes qu'un système d'information atteint ses limites
Avant d'acheter un logiciel ou de lancer une nouvelle base de données, mieux vaut d'abord regarder la situation telle qu'elle est. Cinq symptômes reviennent presque à chaque fois.
Les fichiers se multiplient. Un fichier par personne, par projet, par période ou par bailleur : plusieurs versions finissent par coexister. Le vrai problème n'est pas Excel en tant que tel, mais l'absence de règles sur la façon dont l'information doit être organisée.
Les mêmes données sont saisies plusieurs fois. Le même bénéficiaire peut apparaître dans plusieurs fichiers, la même activité dans plusieurs outils, la même information demandée séparément par plusieurs équipes. Chaque nouvelle saisie est une nouvelle occasion d'erreur.
Les indicateurs ne veulent plus dire la même chose d'une équipe à l'autre. Un projet compte 1 200 bénéficiaires, un autre 1 350, la direction dispose encore d'un troisième chiffre, et tout le monde utilise pourtant le mot « bénéficiaire ». Le problème devient sémantique : que recouvre exactement cet indicateur ? Sans définition commune, deux chiffres parfaitement bien calculés peuvent rester impossibles à comparer.
Le reporting prend plus de temps que l'analyse. Chercher les fichiers, consolider les tableaux, corriger les doublons, vérifier les formules, relancer les collègues pour des données manquantes, reconstruire les mêmes graphiques chaque mois : il ne reste ensuite que très peu de temps pour comprendre ce que ces données racontent réellement.
Une seule personne connaît le système. Elle seule sait où sont les fichiers, comment fonctionne la base, quelle formule utiliser, quel chiffre transmettre, comment produire le rapport. Tant qu'elle est là, tout semble fonctionner. Le jour où elle part, une partie de la mémoire de l'organisation part avec elle : un signal clair que le système repose sur une personne, et non sur une architecture institutionnalisée.
Avant l'outil, comprendre le système
L'une des erreurs les plus coûteuses consiste à commencer par choisir une technologie : « il nous faut Power BI », « nous devons développer une application », « passons sur une base MySQL », « adoptons KoboToolbox ». Ce sont peut-être de bonnes pistes, mais elles répondent à une question qui n'a pas encore été posée : quel problème organisationnel cherche-t-on réellement à résoudre ?
Une bonne démarche part des besoins et des processus, pas des logiciels. Une façon simple de s'y prendre consiste à cartographier le cycle de l'information dans l'organisation : du besoin identifié à la collecte, de la collecte à la validation, du stockage au traitement, de l'analyse à la décision, de la décision à l'action, puis de l'action à l'apprentissage qui nourrit le cycle suivant. Une donnée ne devient réellement utile que lorsqu'elle peut circuler correctement le long de cette chaîne, et chacune de ses étapes doit être maîtrisée, pas seulement la première.
Le modèle d'un SI réellement opérationnel
Une ONG ou une PME aux ressources limitées n'a pas besoin de reproduire l'architecture informatique d'une multinationale. Elle a besoin d'un système proportionné à ses moyens, pensé autour de six dimensions.
Les personnes : qui saisit, qui vérifie, qui analyse, qui décide, qui administre le système ?
Les processus : comment une information entre-t-elle dans l'organisation, comment est-elle validée, corrigée, communiquée ?
Les données : quelles données sont réellement nécessaires, comment sont-elles définies, sous quels formats, avec quels identifiants pour relier les informations entre elles ?
Les technologies : quels outils répondent vraiment au besoin : Excel, KoboToolbox, DHIS2, CommCare, PostgreSQL, MySQL, Power BI, Tableau, Looker Studio, une application développée sur mesure ? Ce choix vient ici, en dernier, pas au début.
La gouvernance : qui est responsable de chaque donnée, qui peut y accéder, quelles règles s'appliquent, comment les changements sont-ils documentés, comment gère-t-on les départs du personnel ?
La décision : que veut-on faire de cette information ? C'est souvent la dimension oubliée. Un SI qui collecte, stocke et analyse parfaitement les données mais n'influence aucune décision reste, au fond, un simple système de production d'information. Un bon SI doit contribuer au pilotage de l'organisation.
Construire une architecture simple, en quatre niveaux
Niveau 1 : Collecter
La collecte doit être adaptée au contexte plutôt qu'à la mode du moment. Excel ou Google Sheets pour certains suivis internes, KoboToolbox pour les enquêtes et collectes terrain, DHIS2 pour certains systèmes institutionnels de santé, CommCare pour des workflows plus structurés, le papier lorsque les contraintes du terrain l'imposent encore : il n'existe pas de mauvais outil en soi, seulement des outils mal adaptés à un besoin donné. Dans certaines zones rurales, une solution qui fonctionne hors connexion sera plus pertinente qu'une plateforme sophistiquée exigeant un réseau permanent. Le contexte opérationnel doit toujours guider le choix technologique, jamais l'inverse.
Niveau 2 : Structurer et stocker
Une donnée collectée doit avoir un endroit fiable où vivre. Pour une petite structure, un fichier Excel correctement conçu peut suffire un moment. Lorsque les besoins se complexifient, une base relationnelle comme PostgreSQL ou MySQL apporte une meilleure intégrité des données, une gestion plus rigoureuse des relations et des types, une vraie capacité multi-utilisateurs et une possibilité d'intégration avec d'autres outils.
Passer à une base de données n'améliore cependant pas les choses automatiquement : une base mal conçue transforme simplement un désordre visible en désordre plus sophistiqué. Avant de créer la moindre table, il faut avoir compris les entités, les événements, les relations, les règles de gestion et les besoins réels des utilisateurs.
Niveau 3 : Analyser et visualiser
Une organisation n'a pas besoin de vingt tableaux de bord. Elle a besoin des informations qui lui permettent réellement de piloter son activité. Pour certains besoins, Excel suffit encore largement ; pour d'autres, Power BI, Tableau ou Looker Studio permettent de suivre les tendances, comparer les zones, repérer les écarts, détecter les anomalies et alimenter les revues de performance.
Mais un tableau de bord n'est pas une décision. Un graphique peut montrer qu'un indicateur baisse ; il ne dit pas pourquoi. Il faut souvent revenir vers les équipes, les bénéficiaires, les observations de terrain, les données qualitatives, le contexte. La technologie rend l'information visible ; elle ne remplace pas le jugement professionnel.
Niveau 4 : Gouverner
La gouvernance est ce qui transforme un ensemble d'outils en véritable système institutionnel. Elle répond à des questions très concrètes : qui est responsable de chaque donnée, qui peut la consulter, qui peut la modifier, qui la valide, où se trouve la version de référence, comment les changements sont-ils documentés, combien de temps conserve-t-on les données, comment les sauvegardes sont-elles réalisées, que se passe-t-il lorsqu'une personne quitte l'organisation ? Les approches actuelles de gouvernance des données insistent sur la nécessité de considérer ensemble la valeur des données, les droits des personnes concernées, la confiance, la sécurité et les risques, et non l'une de ces dimensions isolément.
La règle fondamentale : une seule source de vérité par information
Imaginez une organisation qui possède un fichier bénéficiaires au niveau du projet, un autre au niveau du MEAL, un troisième au niveau de la direction, et un quatrième transmis au bailleur. Lequel fait foi ? Si personne ne peut répondre immédiatement, l'organisation a un problème.
Il faut définir des sources de référence. Cela ne signifie pas qu'il ne doit exister qu'une seule base dans toute l'organisation : une structure peut très bien avoir plusieurs systèmes spécialisés, un pour les données de collecte, un pour les données financières, un référentiel géographique, un système d'indicateurs institutionnels, un entrepôt pour l'analyse consolidée. Ce qui compte, c'est de savoir en permanence quelle source fait autorité pour quelle information. L'enjeu n'est donc pas tant d'avoir « une seule base » que d'avoir une architecture cohérente et des responsabilités clairement établies.
La qualité des données se joue bien avant le tableau de bord
Une erreur fréquente consiste à traiter la qualité des données comme une étape finale : on collecte, puis on découvre les problèmes au moment du reporting : dates incohérentes, doublons, valeurs manquantes, codes différents, noms de communes écrits de trois façons, indicateurs interprétés différemment selon les équipes.
La qualité doit au contraire être intégrée dès la conception. Quelques règles simples suffisent souvent à produire des gains considérables : un dictionnaire des indicateurs, des nomenclatures communes, des identifiants uniques, des formats standardisés, des contrôles de saisie, des règles de validation, des procédures de correction, un minimum de documentation, des contrôles périodiques. L'objectif n'est pas d'enfermer les équipes dans des procédures lourdes, mais de réduire les erreurs qu'on aurait pu éviter.
La sécurité des données n'est pas une option
Une organisation qui détient des données sur des personnes porte une responsabilité. Dans le secteur du développement, certaines informations sont particulièrement sensibles : identité, coordonnées, situation sociale, données sanitaires, informations concernant des enfants ou des personnes vulnérables.
La sécurité ne se limite donc pas à protéger un fichier par un mot de passe. Il faut au minimum se poser quelques questions simples : qui peut voir ces données (confidentialité), qui peut les modifier (intégrité), comment continuer à travailler en cas de panne (disponibilité), peut-on identifier les modifications importantes (traçabilité), existe-t-il une copie indépendante (sauvegarde), a-t-on réellement testé la récupération (restauration), que se passe-t-il quand une personne rejoint ou quitte l'organisation (gestion des accès), et collecte-t-on vraiment toutes les données qu'on demande (minimisation) ? La protection des données se pense dès la conception du système, pas après coup.
À Madagascar, le contexte compte autant que la technologie
Une architecture pertinente pour une grande organisation internationale ne l'est pas nécessairement pour une petite ONG malgache. Il faut tenir compte de la connectivité réelle, de l'éloignement géographique, des capacités numériques des équipes, de la disponibilité du matériel, des coûts récurrents, du turnover, des langues et habitudes de travail, des exigences des bailleurs, des systèmes institutionnels déjà en place, et de la capacité de l'organisation à maintenir elle-même le système une fois le projet terminé, un enjeu particulièrement sensible dans les zones rurales et éloignées.
Un système très sophistiqué mais impossible à maintenir localement peut, dans les faits, être moins performant qu'une solution plus simple, bien comprise et réellement utilisée au quotidien. La maturité ne consiste pas à viser le plus sophistiqué, mais à choisir le niveau de complexité que l'organisation est réellement capable d'absorber et d'entretenir dans la durée.
De la donnée à la décision : la véritable finalité
C'est ici que se joue la différence entre un système documentaire et un véritable système de pilotage.
Prenons un exemple courant. Un tableau de bord montre que la couverture d'une activité est passée de 72 % à 54 %. C'est une information. Mais la direction doit encore se poser plusieurs questions avant d'agir : cette baisse vient-elle d'un problème d'approvisionnement, d'une rupture de personnel, d'une zone devenue difficile d'accès, d'une erreur de collecte, d'un changement dans la population cible, ou simplement d'une modification de la définition de l'indicateur ? Puis : que doit-on faire ? Et, un peu plus tard : l'action décidée a-t-elle réellement produit un changement ?
On obtient alors une véritable boucle : données, analyse, décision, action, observation, apprentissage, puis nouvelle décision. C'est cette boucle, et elle seule, qui donne au système d'information sa valeur stratégique. Dans le secteur humanitaire, l'information management est précisément conçu pour soutenir ce type d'analyse et de décision, et les principes défendus par OCHA insistent notamment sur l'accessibilité, l'interopérabilité et la redevabilité de l'information.
Le tableau de bord le plus utile n'est pas forcément le plus beau
Il est facile de construire un tableau de bord impressionnant : beaucoup de graphiques, des cartes, des couleurs, des filtres, quelques animations. Mais une question demeure : qui l'utilise réellement, et quelle décision permet-il de prendre ?
Un tableau de bord destiné à la direction n'a pas besoin de cinquante indicateurs. Cinq à dix indicateurs stratégiques, bien définis, fiables et régulièrement discutés en réunion sont généralement bien plus utiles que cinquante mal suivis. Le vrai indicateur de performance d'un tableau de bord n'est pas son esthétique. C'est son usage.
Commencer petit, mais penser à long terme
Une petite ONG n'a pas besoin de construire immédiatement un data warehouse, une architecture cloud complexe et plusieurs applications. Elle peut avancer par étapes.
Mois 1 et 2 : Comprendre. Cartographier les données existantes, identifier les systèmes en place, repérer les doublons, lister les utilisateurs et les décisions vraiment critiques.
Mois 3 et 4 : Structurer. Définir des règles, nettoyer les fichiers critiques, harmoniser les indicateurs, organiser les sauvegardes, clarifier les responsabilités.
Mois 5 à 8 : Intégrer. Introduire une base de données lorsque cela se justifie, connecter progressivement certains outils entre eux, réduire les doubles saisies, mettre en place les premiers flux automatisés.
Mois 9 à 12 : Institutionnaliser. Documenter le système, formaliser la gouvernance, renforcer la sécurité, former les équipes, évaluer l'usage réel du système et ajuster l'architecture en conséquence.
Cette progression n'a rien d'une recette universelle : une petite structure peut avancer plus vite, une organisation multisite aura souvent besoin de bien plus de temps. L'essentiel est de commencer par les problèmes les plus importants, et de faire évoluer le système progressivement plutôt que de vouloir tout refaire d'un coup.
Trois questions pour tester son système d'information
Si demain trois personnes clés quittent l'organisation, le système continue-t-il à fonctionner ? Si la réponse est non, il est probablement trop dépendant de quelques individus.
La direction peut-elle obtenir rapidement une information fiable, sans demander à plusieurs personnes de reconstruire les chiffres à la main ? Si la réponse est non, il existe sans doute un problème d'architecture ou de gouvernance.
Les données produites conduisent-elles réellement à des décisions et à des améliorations concrètes ? Si la réponse est non, ce n'est peut-être pas un logiciel qui manque, mais tout simplement une boucle de pilotage.
Vers un système d'information durable
Un SI durable n'est pas nécessairement le plus moderne. C'est celui que les utilisateurs comprennent, que l'organisation peut maintenir elle-même, qui s'adapte quand les besoins changent, qui reste sécurisé et documenté, qui se transmet quand une personne quitte l'organisation, qui se connecte aux autres systèmes quand c'est nécessaire, et qui, surtout, sert réellement à améliorer les décisions.
C'est pour cette raison que la transformation numérique ne devrait jamais se résumer à l'achat d'un logiciel. Elle engage des personnes, des compétences, des processus, des données, des responsabilités et une culture de travail. La technologie n'en est que le moyen.
Notre rôle, chez Helpazone
C'est précisément à cette intersection entre données, systèmes, compétences et décisions que se situe notre travail chez Helpazone. Notre objectif n'est pas d'installer un outil de plus : c'est d'aider les organisations à comprendre leur propre fonctionnement, à structurer leurs informations, à renforcer les compétences de leurs équipes et à construire des systèmes qu'elles peuvent réellement s'approprier et faire évoluer par elles-mêmes.
Selon les besoins, cet accompagnement peut porter sur les systèmes d'information, pour comprendre l'architecture existante, modéliser les données, concevoir les bases, organiser les flux, documenter et renforcer la gouvernance, sur le MEAL, pour structurer les indicateurs, le suivi, l'évaluation, l'apprentissage et la redevabilité, sur la data analytics, pour transformer des données brutes en informations fiables et exploitables, sur la business intelligence, pour construire des tableaux de bord qui éclairent réellement les décisions, ou encore sur le conseil, pour diagnostiquer l'existant et accompagner la transformation pas à pas.
L'objectif reste toujours le même : ne pas simplement produire davantage de données, mais permettre aux organisations de mieux comprendre leur réalité, et de mieux agir.
Un bon système d'information ne se voit pas toujours
Le meilleur système d'information n'est pas forcément celui qui impressionne le plus. Il est parfois presque invisible : les équipes savent où trouver l'information, les données sont suffisamment fiables, les responsabilités sont claires, les erreurs sont détectées rapidement, les informations circulent, les décisions se documentent, et les connaissances restent dans l'organisation même quand les personnes changent. Quand le contexte évolue, le système peut évoluer avec lui.
C'est cela, la maturité d'un système d'information : passer du fichier à la structure, de la structure à l'information, de l'information à la décision, et de la décision à l'action. Une organisation n'a pas besoin de plus de technologie simplement parce que la technologie existe. Elle a besoin d'un système qui l'aide à mieux comprendre, mieux décider et mieux agir. Et c'est peut-être là, à l'ère de la donnée, que commence vraiment la transformation d'une organisation.