Transformation digitale pour les ONG et les organisations internationales

La plupart des manuels de transformation digitale sont écrits pour le monde corporate : un financement stable, une seule langue de travail, un siège qui peut recruter sa propre équipe produit, et un client qui paie pour le service. Les ONG et les organisations internationales évoluent dans presque aucune de ces conditions. Le financement est par projet, à durée limitée. Les utilisateurs sont des équipes terrain dans des endroits où la bande passante est intermittente et l’infrastructure peu fiable. Le « client » est souvent un bénéficiaire qui ne paiera jamais, tandis que le bailleur se trouve sur un autre continent et rend des comptes à son propre conseil sur un autre cycle.

Cela ne rend pas la transformation digitale des ONG plus difficile que sa version corporate, cela lui donne une autre forme. Les risques ne sont pas dans les choix de technologie ; ils sont dans les hypothèses cachées dans la manière dont le travail est financé, dans qui détient la plateforme au jour 731, et dans la capacité de l’équipe terrain à enregistrer un dossier sur un réseau mobile saturé d’un bureau régional pendant la saison des pluies. Cet article passe en revue les contraintes qui décident vraiment si une transformation d’ONG s’installe ou non.

Le problème structurel central de la transformation digitale d’ONG, c’est que les financements couvrent typiquement la construction, pas l’exploitation. Un bailleur finance un projet de 18 mois pour déployer un nouveau système de gestion des bénéficiaires. Le projet se termine dans les délais, la plateforme est en production, et le budget qui payait les développeurs, l’infrastructure cloud et le support s’évapore. Deux ans plus tard, le système est soit bloqué sur une version non maintenue de ses dépendances, soit silencieusement abandonné au profit d’un tableur que quelqu’un a reconstruit parce que c’était plus simple à demander.

La correction honnête n’est pas technique, elle est financière : le coût total de possession, hébergement, support, correctifs de sécurité, formation des nouveaux arrivants, petites améliorations continues, doit être chiffré et nommé au stade de la proposition, et soit intégré au financement initial, soit à un financement de suite, soit absorbé par le budget de fonctionnement de l’organisation. Là où cette conversation n’a pas lieu en amont, la durée de vie de la plateforme est fixée par le cycle de financement initial, indépendamment de la qualité de la construction. Le schéma complet est détaillé dans ce qu’il faut pour réussir les projets digitaux dans les contextes émergents, qui est plus proche de la réalité terrain que la plupart des documents d’achat ne l’admettent.

L’équipe censée utiliser le système est rarement assise dans un siège avec une fibre fiable. Elle est dans un bureau régional sur une connexion 3G, sur une moto entre deux sites, ou dans un centre communautaire qui a six heures d’électricité par jour. Quoi qu’ait l’air la plateforme dans une démo à Paris ou à Genève, c’est l’expérience terrain qui détermine si les vraies données sont saisies, ou si l’équipe retombe sur des formulaires papier que quelqu’un retape trois semaines plus tard sans avoir été présent.

Trois contraintes reviennent. La première est la bande passante : le système doit fonctionner sur des connexions lentes et intermittentes, avec une saisie hors-ligne pour les moments où il n’y a aucune connexion. La deuxième est la langue : l’anglais ou le français du siège n’est que rarement la langue de travail des personnes qui saisissent les données, et un système qui exige de traduire son propre travail dans une autre langue au moment de la saisie produira des données auxquelles personne ne fera confiance. La troisième est les terminaux : l’hypothèse réaliste est un téléphone Android d’entrée de gamme acheté il y a deux ou trois ans, pas un ordinateur portable, et certainement pas le dernier modèle. Concevoir pour cet environnement est un choix délibéré. Concevoir pour un navigateur de bureau moderne en supposant que « ça marchera aussi sur mobile » est le choix par défaut qui produit silencieusement des systèmes inutilisables.

Les plateformes d’ONG ont deux missions qui tirent souvent dans des directions opposées. Elles doivent servir le terrain, rendre la mise en œuvre des programmes plus rapide, plus sûre et mieux documentée pour les gens qui la font. Et elles doivent servir le bailleur, produire des indicateurs, des données de suivi-évaluation et un reporting de redevabilité contre un cadre logique écrit avant que le projet ne commence.

Quand ces deux missions ne sont pas conçues ensemble, l’une gagne et l’autre perd. Si la plateforme est construite autour des exigences de reporting du bailleur, l’expérience terrain devient un long formulaire que les équipes remplissent mal et avec ressentiment, ce qui corrompt les indicateurs mêmes que le bailleur voulait au départ. Si elle est construite uniquement autour de l’expérience terrain, les données sont bonnes mais ne peuvent pas être agrégées dans les indicateurs dont le bailleur a besoin, et le prochain financement devient plus difficile à obtenir. La bonne conception est celle où le workflow terrain génère naturellement les données du bailleur comme sous-produit, pas comme une étape séparée. Cela suppose que l’équipe suivi-évaluation et l’équipe d’opérations terrain soient dans la même salle au moment de la conception, ce qui est un choix de gouvernance plus qu’un choix technique.

Une plateforme d’ONG durable se distingue d’une plateforme corporate durable sur trois points précis.

D’abord, la stack technologique est délibérément ennuyeuse. Des frameworks ennuyeux, des bases de données ennuyeuses, un hébergement ennuyeux, le genre de choses qu’un développeur junior recruté localement dans trois ans pourra encore maintenir. La sophistication dans la stack est un luxe que seules les organisations dotées d’une équipe d’ingénierie permanente en interne peuvent se permettre.

Ensuite, le savoir ne reste pas chez le prestataire qui a construit. Le plan de transmission fait partie du projet dès le premier jour, pas une étape rajoutée à la clôture. La documentation est écrite pour le mainteneur, pas pour le bailleur. Les compétences sont réellement transférées localement, c’est-à-dire que l’équipe locale peut non seulement faire tourner le système, mais aussi l’étendre, le déboguer et décider quand le retirer.

Enfin, la gouvernance survit aux rotations de personnel. Le propriétaire de la plateforme n’est pas « le chef de projet parti dans une autre agence l’été dernier », mais un rôle nommé à l’intérieur de l’organisation qui persiste quand les individus changent. C’est la même discipline de gouvernance qui permet à n’importe quel programme de transformation de survivre à son sponsor, adaptée à un environnement où la rotation est plus rapide et les financements plus fragmentés.

La transformation digitale des ONG et des organisations internationales n’est pas une version au budget rogné du manuel corporate. C’est un problème différent, d’une autre forme, défini par des cycles de financement qui se ferment, des environnements terrain qui contraignent et des obligations de reporting qui traversent le travail. Les plateformes qui durent sont celles qui sont conçues pour ces réalités dès le départ, pas adaptées après coup.

Le contexte plus large, ce qui fait qu’un projet digital tient dans la durée dans des environnements aux budgets limités, à la connexion intermittente et à la rotation rapide des équipes, est rassemblé dans le cluster Madagascar et Afrique. Et lorsque la question n’est plus « devons-nous construire cette plateforme » mais « comment la construire pour qu’elle fonctionne encore dans trois ans, après le départ du chef de projet et la fermeture du financement », c’est exactement ce sur quoi mon accompagnement plateformes digitales pour ONG et institutions est construit.