Système interne vieillissant : le réparer ou le reconstruire

La situation à laquelle les entreprises font face aujourd'hui

Les entreprises dont le système interne est en service depuis plus de dix ans se trouvent généralement dans la même situation. Le système fonctionne toujours. Aucune panne majeure n'est à déplorer. Seulement, la moindre demande prend deux semaines, et une seule personne dans l'entreprise est capable de la traiter.

Cet état est dangereux parce que le problème se dégrade progressivement. Un système qui s'arrête brutalement obtient immédiatement un budget. Mais un système qui ralentit un peu et qui réclame un peu plus de travail chaque année passe la revue annuelle sous la formule : « cette année encore, nous avons tenu tant bien que mal. » Lorsque ces années s'accumulent, trois échéances surviennent en même temps.

Premièrement, le collaborateur qui connaît le système part à la retraite. Les règles métier non documentées disparaissent avec lui. Deuxièmement, le support de sécurité des technologies socles prend fin. Pour un langage ou une version de base de données qui n'est plus maintenu, aucun correctif ne paraît lorsqu'une vulnérabilité est découverte. Troisièmement, il devient impossible d'ajouter de nouveaux besoins. La prise en charge du mobile, l'intégration de services externes ou l'analyse de données se voient opposer un refus continu : « ce n'est pas possible avec le système actuel. »

Au moment où ces trois échéances se présentent conjointement, la seule option restante est la refonte complète. Or la refonte complète est l'option la plus coûteuse et la plus risquée.

Cinq signaux qui imposent d'envisager le remplacement

Si trois des points suivants au moins vous concernent, le moment est venu d'engager l'examen d'un remplacement.

1. Le coût du changement est asymétrique. Ajouter un champ à un écran prend plusieurs jours. Lorsque, du point de vue de l'utilisateur, la durée de développement d'une demande mineure et celle d'une demande majeure diffèrent peu, la structure ne supporte déjà plus le changement.

2. La maintenance repose sur une seule personne. Un système auquel une seule personne peut toucher fait de ses congés et de son départ un risque pour l'activité. Il ne s'agit pas d'un problème de ressources humaines mais d'un problème de structure.

3. Le support des technologies socles a pris fin. Vérifiez les dates officielles de fin de support du moteur d'exécution du langage, du cadriciel et de la base de données utilisés. Si elles sont déjà passées, l'incident de sécurité n'est qu'une question de temps.

4. Les données ne peuvent pas être exploitées. Si obtenir les chiffres nécessaires à une décision de direction impose à un collaborateur d'écrire lui-même une requête, ou d'ouvrir plusieurs écrans pour additionner à la main, c'est que le système enferme les données.

5. Les contournements se multiplient. Si le périmètre que les métiers gèrent sous tableur plutôt que dans le système s'étend, cela signifie que le système ne reflète plus le travail réel. Ce contournement n'étant consigné nulle part, le problème reste invisible tant que l'on n'observe que le système.

Calculez le coût du maintien

Si le débat sur le remplacement n'avance pas, c'est généralement à cause d'une question : « pourquoi dépenser alors que cela fonctionne encore ? » Pour y répondre, il faut démontrer par des chiffres que le maintien engendre lui aussi des coûts. Additionnez les quatre postes suivants.

Les trois premiers postes correspondent à des dépenses déjà engagées mais qui n'apparaissent sur aucun compte. Le quatrième correspond à un coût encore inexistant mais qui s'accumule en probabilité.

Ce qui suit est un exemple hypothétique destiné à illustrer la méthode de calcul ; les valeurs réelles varient selon les conditions propres à chaque entreprise. Avec 30 demandes de modification par an, une attente moyenne de 10 jours par demande et un coût d'opportunité journalier de l'attente fixé à 150 000 KRW, le seul coût des retards atteint 45 000 000 KRW par an. Si, en outre, deux services consacrent chacun cinq heures par semaine à une double gestion sous tableur, 13 000 000 KRW par an s'y ajoutent sur la base d'un coût salarial complet horaire de 25 000 KRW.

Si le total s'établit à 58 000 000 KRW par an, il représente 170 000 000 KRW sur trois ans. C'est à ce moment seulement qu'apparaît un chiffre comparable au coût d'un remplacement. Le maintien n'est pas gratuit : c'est une dépense pour laquelle aucune facture n'arrive.

Pourquoi la refonte complète est risquée

Une fois le remplacement décidé, la première méthode qui vient à l'esprit est la refonte complète : arrêter l'ancien, construire le nouveau et basculer d'un coup, un jour donné. La démarche est intuitive, mais elle porte trois risques.

Le bénéfice reste nul jusqu'à la fin du projet. Pour une refonte de douze mois, l'organisation paie pendant onze mois sans percevoir la moindre amélioration. Si le contexte économique change durant cette période, le projet subit une pression d'arrêt.

Les exigences vieillissent en cours de route. Les exigences arrêtées au lancement diffèrent des besoins que les métiers expriment un an plus tard. Répercuter cet écart décale le calendrier ; ne pas le répercuter aboutit à un système déjà dépassé.

Le risque se concentre au moment de la bascule. Toutes les fonctions changeant en une fois, il n'existe guère de moyen de revenir en arrière si un incident survient le jour de la bascule. Et un incident survient presque toujours, car il subsiste immanquablement dans l'ancien système des règles d'exception dont plus personne ne se souvient.

La migration progressive comme alternative

Plutôt qu'un remplacement intégral, il existe une approche consistant à transférer les fonctions une à une tout en conservant le système existant. L'ordre est le suivant.

Étape 1 — Tracer les frontières

Découpez le système actuel en blocs fonctionnels. Découpez par unité métier — commandes, stocks, facturation, ressources humaines — mais tracez les lignes selon le propriétaire des données. Si plusieurs blocs modifient directement la même table, ce point deviendra plus tard l'obstacle principal.

Pour tracer ces frontières, suivez les flux de données et non l'organigramme. Si deux services distincts modifient conjointement les mêmes données, ils forment un seul bloc ; et si, à l'intérieur d'un même service, les données sont entièrement séparées, le découpage est possible.

Étape 2 — Séparer d'abord la lecture

Le premier chantier le plus sûr concerne les fonctions de consultation. Tableaux de bord, statistiques, rapports : les fonctions qui se contentent de lire les données peuvent être construites dans le nouveau système sans affecter l'existant. En cas d'échec, les écrans en place demeurent, le retour en arrière est simple, et les métiers perçoivent immédiatement l'amélioration.

Cette étape produit un effet secondaire supplémentaire. En construisant les fonctions de consultation, les défauts des données existantes apparaissent : clients en doublon, dates au format corrompu, lignes dont la valeur de code est vide. Il est essentiel de découvrir ces défauts avant de transférer les fonctions d'écriture.

Étape 3 — Transférer les fonctions d'écriture

Une fois la vérification par la consultation achevée, transférez les fonctions de saisie et de modification. Deux systèmes manipulant alors les mêmes données pendant un certain temps, désignez un seul côté comme source de référence. Laisser les deux côtés modifier simultanément produit des incohérences dont la recherche coûte plus de temps que la migration elle-même.

Pour l'ordre de transfert, commencer par les fonctions peu utilisées et à faible portée est plus sûr. Mais transférer d'abord des fonctions que personne n'utilise ne permet aucune vérification : une fonction réellement utilisée mais dont l'arrêt d'une journée serait tolérable constitue le meilleur point de départ.

Étape 4 — Réduire le système existant

Les fonctions transférées doivent être supprimées du système existant. Si elles sont laissées en place, une partie des métiers continuera d'utiliser les anciens écrans et l'entreprise finira par maintenir deux systèmes indéfiniment. Repousser cette étape est la cause la plus fréquente d'échec d'une migration progressive.

Si la suppression est difficile, bloquez au minimum les accès et passez la fonction en lecture seule. Puis fixez par une date le moment de son retrait définitif. Un plan de nettoyage sans date n'est jamais exécuté.

Quelle option retenir

La refonte complète n'est pas toujours un mauvais choix. Si le périmètre est restreint, si les règles métier sont consignées dans des documents et si quelques heures d'interruption sont tolérables, changer en une fois est plus rapide et moins coûteux. Le critère de décision n'est pas l'âge du système mais l'endroit où les règles sont consignées.

Ce qui pose réellement problème lors de la migration des données

Les retards de calendrier tiennent le plus souvent aux données et non au développement des fonctions. Les systèmes anciens accumulent des situations telles que les suivantes.

• Un même client enregistré plusieurs fois sous des libellés différents
• Des formats de dates, de numéros de téléphone et de numéros d'entreprise variant selon les périodes
• Des lignes vides sur des champs pourtant obligatoires
• Des données faisant référence à des valeurs de code désormais supprimées
• Des lignes seulement marquées comme supprimées mais physiquement conservées

Découverts pendant la phase de migration, ces problèmes décalent immanquablement le calendrier. Enquêtez en amont, avant le lancement, et déterminez d'abord ce qui sera nettoyé et ce qui sera abandonné. Vouloir assainir parfaitement l'intégralité des données historiques empêche la migration d'aboutir. Nettoyer les seules dernières années et conserver le reste en consultation seule est souvent l'option réaliste.

L'occasion de reconcevoir la sécurité et les droits d'accès

Un remplacement constitue aussi une occasion rare de remettre en ordre le dispositif de sécurité. Les systèmes anciens présentent généralement une séparation des droits relâchée, la plupart des collaborateurs pouvant consulter davantage de données que nécessaire. Traitez les points suivants au cours de la migration.

La minimisation des droits d'accès. Faites en sorte que chaque rôle ne voie que les données qui lui sont nécessaires. Reprendre telle quelle la structure de droits du système existant revient à transférer aussi ses défauts.

Le lieu de stockage et la durée de conservation des données à caractère personnel. Établissez quelles données personnelles sont stockées, où, et à quel moment elles sont détruites. En cas de migration vers le nuage, le pays de stockage des données doit également être vérifié.

La conservation de l'historique des traitements. Consignez qui a modifié quoi et quand. Faute de cet enregistrement, de nombreux systèmes anciens ne permettent pas de remonter à la cause lorsqu'un incident survient.

Comment convaincre la direction

Le budget d'un remplacement passe rarement sur une argumentation technique. « La structure est vieillissante », « le support technique a pris fin » : ces explications ne se traduisent pas en urgence pour un décideur. Reformulez-les selon les trois axes suivants.

Le montant qui fuit aujourd'hui. C'est le total des coûts de retard, de contournement et d'erreur calculés plus haut. Le point essentiel est que cette dépense est déjà engagée, remplacement ou non.

Ce que l'on ne parvient pas à faire. Dressez la liste des demandes rejetées au cours de l'année écoulée au motif que « le système actuel ne le permet pas ». Placez en tête celles qui touchent au chiffre d'affaires ou à la perte de clients. Le manque à gagner est un argument plus puissant que le coût de maintien.

Le pire scénario. Estimez la durée et le coût du rétablissement si l'unique responsable venait à partir ou si un incident survenait sur un composant en fin de support. Même à faible probabilité, une ampleur élevée fait bouger la décision.

Après avoir exposé ces trois axes, ne demandez l'approbation que pour la première étape de la migration progressive. Réclamer l'intégralité du budget en une fois allonge la durée d'examen, et la situation se dégrade entre-temps.

Comment établir le calendrier et les ressources

Dans une migration progressive, c'est souvent le calendrier qui dérape. Intégrez trois éléments par avance.

Inscrivez le temps des métiers au calendrier. Dans un projet de migration, la ressource la plus rare n'est pas le développeur mais le collaborateur métier qui connaît les règles. Ces personnes participent en parallèle de leur activité principale : sans accord préalable sur le temps qu'elles peuvent y consacrer, chaque phase de vérification prend du retard.

Intégrez au calcul la période d'exploitation en parallèle. Après le transfert d'une fonction, les deux systèmes doivent coexister pendant un certain temps. Pendant cette période, la charge d'exploitation augmente au lieu de diminuer. Ne pas en tenir compte dans le calendrier et le budget conduit à un manque de ressources lors de la dernière étape.

Prévoyez une période distincte pour le nettoyage des données. Les questions d'intégrité des données évoquées plus loin peuvent être traitées en parallèle du développement, mais elles réclament un temps et des personnes dédiés. Noyées dans le calendrier de développement, elles prendront du retard à coup sûr.

Ce qu'il faut vérifier avec un prestataire externe

Il est fréquent qu'une migration ne puisse être menée avec les seules ressources internes. Si vous envisagez un prestataire externe, vérifiez les points suivants avant la signature.

Les livrables comprennent-ils de la documentation ? Ne recevoir que du code fait réapparaître le même problème quelques années plus tard. Le référentiel des règles métier, la description de la structure des données et les procédures d'exploitation doivent figurer parmi les livrables.

Les modalités de transfert de compétences après la migration sont-elles définies ? Une fois la mise en œuvre achevée, les équipes internes doivent pouvoir exploiter le système. Précisez au contrat la durée du transfert de compétences et le périmètre de la formation.

Le contrat peut-il être découpé par étapes ? Contracter l'ensemble en une fois rend difficile tout changement de cap en cours de route. Réaliser la première étape puis décider de la suite est une structure plus sûre pour les deux parties.

Les droits sur nos données sont-ils clairs ? Si des données réelles sont utilisées durant le développement, fixez par écrit quelles données se déplacent, vers où, et comment elles sont détruites à la fin.

Ce qu'il faut préparer avant le lancement

Quelle que soit l'approche retenue, assurez-vous des trois éléments suivants avant le lancement.

La documentation des règles métier en vigueur. Les règles qui n'existent que dans le code sont immanquablement perdues au cours de la migration. Sans viser une spécification parfaite, consignez au moins par écrit la gestion des exceptions et les conditions d'approbation.

Le contrôle de l'intégrité des données. Examinez l'état actuel au regard des points énumérés plus haut et déterminez le périmètre du nettoyage.

Un plan de retour en arrière. Pour chaque étape, définissez comment revenir en arrière en cas de problème. Une étape irréversible est en elle-même une étape trop grande : c'est le signe qu'il faut la découper plus finement.

Synthèse

Le coût d'un système vieillissant ne se manifeste pas sous forme de pannes mais sous forme de retards et de dépendance. C'est pourquoi il est perçu tardivement.

• Examinez les cinq points suivants : coût du changement, concentration des compétences, fin du support technique, accessibilité des données, contournements.
• Calculez le coût du maintien selon les quatre postes retards, contournements, erreurs et risque, afin d'obtenir un chiffre comparable au coût d'un remplacement.
• Si les règles n'existent que dans le code, la refonte complète est risquée.
• Transférez d'abord les fonctions de consultation, et supprimez impérativement du système existant les fonctions transférées.
• Examinez l'intégrité des données avant le lancement et fixez à l'avance le périmètre du nettoyage.
• Profitez de cette occasion pour reconcevoir les droits d'accès et la politique de conservation des données à caractère personnel.

Plus important que la décision de remplacer est le fait de ne pas la repousser. Si trois des cinq signaux vous concernent, engager l'examen dans l'année revient moins cher qu'une refonte complète l'année suivante.