Refactoriser l’administration

Dans le milieu du développement logiciel, il existe une bonne pratique qui s’appelle « refactoriser ». Refactoriser implique de reprendre le code déjà écrit. Pas pour ajouter de nouvelles fonctionnalités. Plutôt pour rendre le code plus clair, plus lisible et plus maintenable. Enlever le superflu. Supprimer les doublons. Ré-écrire le code source afin que le logiciel produise les mêmes résultats, mais de manière à ce qu’il fonctionne sur le long terme et intégré dans un système complexe.

Refactoriser n’est pas la spécialité de l’administration. Quand un nouveau problème surgit, souvent une nouvelle structure est créée. Et si plus tard le même problème réapparaît, le premier réflexe sera de créer encore une nouvelle entité pour le résoudre. Sans modifier l’ancienne. Sans la supprimer. En laissant des couches et des couches de structures sédimenter les unes sur les autres. Ce qui génère généralement de nouveaux problèmes…

En développement, cela s’appelle le « code spaghetti ». Des morceaux qui partent dans tous les sens, indémêlables, adhérents les uns aux autres. Quand les développeurs rencontrent du code spaghetti, ils n’ont qu’une envie : tout jeter à la poubelle afin de repartir de zéro.

Je préférerais que l’administration ne finisse pas un jour par être jeter toute entière à la poubelle afin de repartir de zéro. Pour limiter les chances que cela arrive, passer du temps à la refactoriser me semble important. Au lieu de créer systématiquement de nouvelles structures, essayer de transformer en profondeur celles qui existent. Enlever le superflu. Supprimer les doublons. Ré-écrire nos directives afin que l’administration produise les mêmes résultats, mais de manière à ce qu’elle fonctionne sur le long terme et intégrée dans un système complexe.