De quoi parle-t-on
La dette technique désigne l’écart entre l’état d’un système et l’état dans lequel il devrait être pour rester sûr, maintenable et évolutif. L’obsolescence en est la forme la plus visible : système d’exploitation qui ne reçoit plus de correctifs, logiciel métier dont l’éditeur a cessé le support, langage que plus personne ne pratique dans l’équipe.
Elle prend aussi des formes moins techniques : une application dont un seul agent connaît le paramétrage, une interface bricolée entre deux logiciels, une base de données dont personne ne sait plus qui l’alimente.
Pourquoi le secteur public y est particulièrement exposé
- L’annualité budgétaire favorise le projet neuf, visible, au détriment de l’entretien de l’existant.
- Les logiciels métiers répondent à des réglementations propres au secteur public, le marché compte peu d’éditeurs, parfois un seul, et la sortie est coûteuse.
- Les réorganisations (fusions, transferts de compétences, mutualisations) additionnent les systèmes plus vite qu’elles ne les rationalisent.
- Les compétences partent avec les agents qui ont installé les systèmes, et le recrutement de profils techniques est difficile.
Ce que la dette coûte
Le premier coût est celui du risque. Un composant qui ne reçoit plus de correctifs est une porte ouverte, l’ANSSI souligne dans son panorama annuel l’importance de la gestion des vulnérabilités dans les compromissions qu’elle traite. Le deuxième est celui de l’immobilisme : chaque projet nouveau doit composer avec des systèmes anciens, ce qui allonge les délais et renchérit les intégrations. Le troisième est budgétaire : le maintien en conditions opérationnelles de l’existant absorbe les crédits et les équipes, et laisse peu de marge pour moderniser.
Mesurer : une fiche par application
La mesure ne demande pas d’outil sophistiqué. Pour chaque application rattachée à un processus important, une fiche d’obsolescence renseigne :
- la version en service et la date de fin de support annoncée par l’éditeur ;
- la criticité du ou des processus qu’elle porte ;
- les personnes capables de la maintenir, en interne et chez le prestataire ;
- le coût annuel complet (licences, maintenance, hébergement, temps d’agents) ;
- les dépendances : ce dont elle a besoin, ce qui a besoin d’elle ;
- le coût estimé et les conditions d’une sortie.
Ces fiches font partie des livrables de la méthode DYNAMAP SI. Réunies, elles donnent une image de la dette qu’une direction générale peut lire : combien d’applications critiques sont hors support, combien reposent sur une seule personne.
Décider : quatre options, pas une de plus
| Option | Quand la retenir | Point de vigilance |
|---|---|---|
| Maintenir | Application stable, peu exposée, encore supportée. | Fixer une date de réexamen. |
| Moderniser | Bon socle fonctionnel, technique vieillissante. | Vérifier que l’éditeur a une trajectoire crédible. |
| Remplacer | Hors support, critique, sans évolution possible. | Reprise des données et conduite du changement : le vrai coût est là. |
| Retirer | Usage marginal ou doublon. | Archivage réglementaire des données avant extinction. |
La quatrième option est la plus négligée. Chaque application retirée libère des crédits, de la surface d’attaque et du temps d’équipe. Un plan de résorption crédible commence souvent par là.
Inscrire la résorption dans la durée
La dette ne se solde pas en un exercice. Elle se traite par une ligne pluriannuelle, inscrite au schéma directeur et suivie par un indicateur simple, présenté une ou deux fois par an à la direction générale : part des applications critiques hors support, évolution depuis la dernière présentation. La page budget numérique explique comment présenter cette ligne à une assemblée ou à un conseil.
Dans la méthode DYNAMAP SI
L’obsolescence se repère dès l’analyse de l’existant, se formalise dans les rapports d’étonnement et se suit dans les tableaux de bord.
- 1Phase 1 · Analyse de l’existant : inventorier les actifs, les processus et les risques tels qu’ils sont réellement.
- 2Phase 2 · Rapports d’étonnement : consigner ce qui surprend : applications sans responsable, coûts sans visibilité, dépendances non maîtrisées.
- 7Phase 7 · Tableaux de bord de la DSI : piloter par des indicateurs de risques, de dette, de coûts et d’avancement.
La méthode appliquée au secteur public · Le framework complet sur dynamap.fr
Pour approfondir : les livres de la collection
DYNAMAP SI : le livre du framework
Le livre fondateur : les sept phases de DYNAMAP SI, de l’analyse de l’existant aux tableaux de bord de la DSI. Une approche incrémentale, pensée pour les organisations qui n’ont ni le temps ni les effectifs d’un grand programme d’architecture. La version numérique est gratuite.
L’économie du Système d’Information
Construire, défendre et piloter un budget numérique : dépenses de fonctionnement et d’investissement, coût complet des applications, arbitrages. Pour les DSI qui doivent rendre leurs dépenses lisibles par une direction générale.
Méthode d’audit du Système d’Information
Une méthode d’audit en phases : périmètre et objectifs, planification, collecte, évaluation des risques et de la conformité, vérifications sur le terrain, restitution. Avec les référentiels usuels : ISO 19011, ISO 27001, ITIL, COBIT, RGPD.
Toute la collection est présentée sur la page livres sur le système d’information.
Sources et références
Yann-Eric Devars
Architecte d’entreprise · créateur du framework DYNAMAP SI
Fondateur de Solve DSI, il accompagne depuis près de dix ans des organisations dans la cartographie et la gouvernance de leur système d’information. Il publie sur LinkedIn ses analyses sur les systèmes d’information publics ; les échanges entre pairs y sont ouverts.