Pourquoi les projets numériques municipaux déraillent si souvent
Notre fondateur, Anthony, revient sur deux ans de travail avec des municipalités et des OBNL pour mettre en lumière trois angles morts qui freinent encore trop souvent les projets numériques dans le secteur public.
Ce que j’observe après deux ans à travailler avec des municipalités
Ça fait environ deux ans que je travaille principalement avec des municipalités et des OBNL. Le secteur public me tient vraiment à cœur. C’est pour ça que j’ai décidé d’écrire cet article.
On entend souvent du monde chialer sur l’inefficacité du secteur public sans vraiment pointer ce qui ne fonctionne pas. Ce que je vais partager ici, ce n’est pas pour alimenter ce genre de discours. C’est pour nommer des choses que je vois sur le terrain, dans l’espoir que ça fasse réfléchir, parce que je crois sincèrement que beaucoup de ces problèmes se règlent sans jeter plus d’argent dessus ni couper dans le gras.
Voici les trois schémas que je rencontre à peu près partout.
1. La délégation à outrance
LE PROBLÈME LE PLUS FRÉQUENT DE LOIN!
Quand un gestionnaire ne se sent pas à l’aise avec la technologie, il délègue. C’est normal. C’est humain.
Sauf que dans plusieurs projets, la délégation va trop loin. On délègue l’exécution, les choix techniques, puis tranquillement, on délègue aussi la compréhension de ce qu’on est en train de faire.
Le gestionnaire devient un approbateur. Il signe des livrables qu’il comprend à moitié. Et les gens à qui on a délégué, eux, ne se sentent pas propriétaires du projet, parce qu’ils ne l’ont jamais vraiment été.
Résultat : quand quelque chose accroche, tout le monde se renvoie la balle. La communication devient difficile. Les décisions traînent. Et si le projet déraille, personne ne sait trop où ça a cassé, parce que la responsabilité était éparpillée entre trop de monde.
2. Rester dans les sentiers battus, mais sans vraiment connaître le sentier
Petite précision : je parle ici surtout de projets modestes, souvent pensés pour améliorer l’administration à l’interne. Pas de mégaprojets numériques pour, disons, une société automobile d'État. *Tousse tousse.*
Je comprends la logique. SharePoint, Power Automate, l’environnement Microsoft : c’est ce que les équipes connaissent. Et quand le consultant ou le fournisseur repart, il faut bien que quelqu’un soit capable de maintenir ça à l’interne.
Sauf que dans la réalité, ce « quelqu’un » existe rarement.
Ce qui arrive, c’est que le fournisseur est rappelé quelques mois plus tard. Mais il travaille maintenant dans une solution qui a été choisie pour être « facile à maintenir », pas pour être solide. Et les limites de cette solution commencent à peser.
SharePoint, ce n’est pas un mauvais outil. Mais c’est un système de gestion de fichiers, pas une base de données. Bâtir une stratégie numérique là-dessus en se disant qu’on verra plus tard pour les données structurées, c’est une décision qui finit par se payer.
3. Beaucoup d’analystes d’affaires, très peu d’ingénieurs de données
C’est peut-être le point qui m’a le plus surpris depuis deux ans.
La plupart des municipalités ont des gens capables de documenter des processus, de cartographier des flux et d’identifier des besoins. Les analystes d’affaires sont là.
Ce qui manque presque partout, c’est quelqu’un qui comprend vraiment les données : leur structure, leur qualité, leurs incohérences. Quelqu’un capable de dire : « Ces deux systèmes ne se parlent pas, et si on construit par-dessus sans régler ça, on automatise juste le problème. »
Ce qui m’a frappé, c’est que même dans des municipalités d’envergure, Azure est à peine exploité. Excel et SharePoint restent les outils de référence, pas parce que c’est le bon choix technique, mais parce que c’est ce que le monde connaît et que personne à l’interne ne pousse vraiment pour aller ailleurs.
Cartographier un processus bancal en détail, ça ne le rend pas moins bancal. Et sans quelqu’un qui comprend la couche de données, les projets s’appuient sur des bases que personne n’a vraiment inspectées. Ça finit toujours par rattraper.
En résumé
Ces trois problèmes sont liés.
Un gestionnaire qui délègue trop ne posera pas les bonnes questions sur les données. Une équipe qui reste dans ses outils confortables ne réalisera pas les limites de sa base technique. Et sans expertise en données à l’interne, personne ne voit venir le mur.
La bonne nouvelle, c’est que nommer ces choses, c’est déjà la moitié du chemin.