Votre application repose sur une technologie obsolète
Elle fait encore le travail. Mais son socle ne reçoit plus de correctifs, et chaque changement coûte plus cher que le précédent.
Ça vous dit quelque chose ?
Votre application a été bien construite, avec les outils de son époque. Elle gère vos devis, vos commandes, et elle fait encore le travail. Mais son framework a cessé d'évoluer. Le monde autour d'elle, lui, a continué.
- Le framework, le langage ou la base de données n'est plus maintenu : AngularJS, PHP 5 ou 7, une ancienne version de Java ou du .NET Framework. Plus aucun correctif de sécurité ne sort.
- Votre hébergeur ou votre fournisseur cloud annonce la fin d'une version, avec une date, et vous demande de migrer.
- Des bibliothèques ont des failles connues, mais personne n'ose les mettre à jour, de peur de tout casser.
- L'application ne se compile ou ne se met en ligne que depuis une vieille machine, que personne ne veut éteindre.
- Les développeurs refusent d'y toucher, ou demandent plus cher pour le faire. Votre propre équipe, elle, a d'autres priorités.
- Un partenaire modernise son API, et une intégration qui marchait depuis des années casse du jour au lendemain.
Ce que cette technologie vous coûte vraiment
Une technologie obsolète ne coûte rien tant que rien ne bouge. Le problème, c'est que tout bouge autour d'elle.
-
L'exposition
Depuis la dernière mise à jour de votre application, combien de failles ont été publiées pour ses composants ? Et qui s'en apercevrait si l'une d'elles était exploitée ?
-
L'incident
Si l'hébergeur retire l'ancienne version à la date annoncée, ou si une intégration casse lundi matin, combien de temps votre équipe peut‑elle travailler sans l'outil ?
-
Le prix de chaque changement
Combien a coûté la dernière petite modification ? Plus ou moins que la même il y a trois ans ?
-
Le recrutement
Combien de développeurs acceptent encore de travailler sur cette technologie, et à quel prix ?
Personne n'additionne ces coûts, et ils grandissent tant que rien ne change. Le jour où l'un d'eux devient urgent, vous décidez sous la pression d'une panne.
Cette semaine, sécurisez
Cinq vérifications qui ne touchent pas au code. Utiles même si vous ne nous appelez jamais.
- Les versions. Notez les versions exactes du langage, du framework, de la base de données et du système d'exploitation du serveur, et la date de fin de support de chacune : elle est publique.
- Ce qui est exposé. Listez ce qui est accessible depuis Internet : l'application, ses écrans d'administration, ses API, parfois la base de données. Ce qui n'a pas besoin d'être public peut souvent être fermé ou filtré sans toucher au code.
- Les sauvegardes. Une copie récente de la base et du code, hors de l'hébergement, et un essai de restauration. Avant toute mise à jour, c'est votre filet.
- La machine qui construit. Si un seul ordinateur sait compiler l'application et la mettre en ligne, ne l'éteignez pas : faites-en une copie complète, et faites écrire la marche à suivre.
- Les intégrations. Listez les services externes auxquels l'application se connecte (paiement, comptabilité, portails de partenaires, envoi d'e‑mails), et inscrivez‑vous à leurs annonces de changement.
La liste complète, avec les accès et le nom de domaine : reprise d'application existante.
Sécuriser, mettre à jour ou reconstruire ?
Il n'y a pas une réponse pour toutes les applications. Il y a un ordre.
-
Sécuriser ce qui est exposé
Fermer ce qui n'a pas besoin d'être public, mettre à jour ce qui peut l'être sans risque, tester les sauvegardes. C'est le correctif urgent du bilan de santé, celui sans lequel nous ne voulons pas vous laisser partir.
Le bilan de santé -
Mettre à jour pas à pas
Poser des tests sur ce qui compte, puis monter les versions une à une, pendant que l'outil tourne. Au forfait, d'abord là où cela rapporte le plus.
Stabiliser -
Reconstruire, quand c'est moins cher
Quand migrer coûte plus cher que repartir sur une base saine. Pas avant.
Reconstruire
Le bilan de santé mesure laquelle de ces options vous coûte le moins. Vous décidez avec des chiffres, pas sous la pression d'une date de fin de support.
Comment nous reprenons votre application
La reprise en trois temps : cadrer, stabiliser, reconstruire. Et toujours le bilan de santé d'abord.
Pour une technologie en fin de vie, le bilan de santé mesure ce qui compte : les versions et les dépendances en retard, ce qui est exposé, et ce que coûte une mise à jour comparée à une refonte.
Vous avez une équipe technique, mais elle est prise par les nouveaux projets ? Nous travaillons à ses côtés : nous prenons la mise à niveau en charge, nous la documentons, et nous lui rendons un outil qu'elle peut de nouveau faire évoluer.
Par où commencer ?
Ou le vrai problème, c'est que votre équipe n'a plus le temps, ou votre développeur est parti ?
Toutes les situations : reprise d'application existante.