L'échec d'un projet de système d'information communal est rarement tonitruant. Il prend le plus souvent la forme d'un logiciel installé mais délaissé, d'une base de données qui se vide lentement, d'agents qui maintiennent leurs registres papier à côté de l'écran. C'est un échec silencieux, aux conséquences pourtant lourdes : finances locales amputées, service aux citoyens dégradé, confiance dans le numérique public érodée.
Les causes de ces échecs ne sont que marginalement techniques. Elles tiennent à la manière dont les projets sont conçus, gouvernés et appropriés.
Une première confusion consiste à réduire le projet à l'achat d'un outil. On numérise alors des procédures sans les avoir repensées. Un système de gestion des permis de construire, par exemple, reproduit le circuit de signatures d'avant, avec les mêmes étapes, les mêmes délais, et une charge de travail supplémentaire de numérisation. L'outil ajoute de la complexité au lieu de la réduire. Un projet SI est d'abord un projet de transformation organisationnelle. Si la commune n'a pas clarifié ses processus avant de les informatiser, elle automatise l'inefficacité.
La résistance des acteurs constitue un deuxième écueil. Les agents communaux peuvent percevoir le nouveau système comme une menace sur leur emploi, une perte de leur pouvoir discrétionnaire ou une source d'insécurité professionnelle. Ignorer ces résistances et se contenter d'une formation technique au logiciel ne suffit pas. Les projets réussis embarquent les agents dès la conception, valorisent les compétences nouvelles et garantissent que nul ne sera licencié à cause de la digitalisation.
Troisième cause de déraillement : le décalage entre le temps politique et le temps technique. Un SI communal se déploie sur dix à quinze ans, tandis qu'un mandat dure cinq ou six ans. La tentation de changer de système à chaque alternance, ou de précipiter un lancement pour afficher des résultats avant une élection, conduit à des ruptures coûteuses. La protection passe par un schéma directeur numérique partagé au-delà des clivages partisans, et par une équipe technique stable, protégée des cycles électoraux.
La dépendance au fournisseur est un quatrième facteur de fragilité. Quand la commune ne possède ni le code source, ni la documentation, ni une compétence interne capable de dialoguer avec le prestataire, elle perd toute maîtrise sur son système. La mutualisation intercommunale des compétences techniques, pratiquée dans plusieurs régions françaises et esquissée en Afrique de l'Ouest par certains groupements de communes, offre une piste pour reconstituer une capacité de pilotage.
Enfin, l'absence de gouvernance des données mine les projets. Des doublons dans les fichiers des contribuables, des adresses saisies sans standard, des identifiants inexistants : le SI ne fait alors qu'afficher un désordre. Désigner un responsable de la qualité des données, avant même le déploiement du logiciel, est une condition nécessaire — mais rarement remplie.
Ces cinq causes ne sont pas des fatalités. Des communes, au Maroc comme ailleurs, commencent à structurer leurs projets autrement : en partant des processus, en associant les agents, en se dotant d'une gouvernance de la donnée. L'échec des SI communaux n'est pas une malédiction, mais le produit de choix évitables.