Moderniser l’application dont tout dépend.

Garder — et sécuriser autour

Probablement rien à réécrire.

Rien ne brûle : la bonne dépense n’est pas un projet, c’est un état des lieux daté. Nous inventorions, nous documentons ce que personne n’a écrit, nous listons les composants hors support avec leurs échéances, et nous sécurisons ce qui entoure l’application — sauvegarde réellement restaurée, accès nominatifs, journalisation. Vous ressortez avec une carte et un calendrier, pas avec un chantier.

Réhébergement

La déplacer d’abord, décider ensuite.

Une échéance courte et un service qui ne peut pas s’arrêter : la seule manœuvre raisonnable est de sortir l’application du serveur qui va s’éteindre, sans y toucher. Elle repart telle quelle sur un socle supporté — machines virtuelles Azure ou infrastructure locale renouvelée — avec la sauvegarde et la supervision qui vont avec. Cela n’améliore pas l’application ; cela achète le temps de décider correctement.

Replateformage

Changer le socle, garder le code.

C’est la trajectoire la plus fréquente, et la plus sous-estimée. On ne réécrit pas la logique métier : on remonte le cadriciel, on déplace la base de données vers une version supportée ou vers Azure SQL, on remplace les accès qui vont disparaître, on reconstruit la chaîne de livraison. L’application rend le même service, sur des fondations qui tiennent encore dix ans, pour une fraction du coût d’une réécriture.

Encapsulation

L’enfermer derrière une interface.

On ne réécrit pas ce qu’on ne peut pas lire, et on ne le jette pas non plus tant qu’il rend service. Nous l’exposons proprement par un web service documenté, puis nous construisons le neuf autour : les nouveaux usages passent par l’interface, l’ancien cœur continue de tourner, et il se remplace ensuite morceau par morceau. La règle qui vaut ici comme partout : ce qui est spécifique vit à part, hors de l’application qui l’utilise et hors du système qui en consomme les résultats — donc testable, versionnable, supervisable.

Remplacement

Un produit du marché, et l’intégration qui va avec.

Si un produit couvre largement le besoin, le développement spécifique serait une dépense mal placée — et nous le disons même si nous savons le faire. Le travail se déplace alors là où il est vraiment : le cahier des charges, l’analyse comparative des réponses, la reprise des données, et les interfaces avec le reste de votre système. C’est en général là que ces projets échouent, pas dans le choix du produit.

Redéveloppement

La redévelopper, par lots.

Le besoin est propre à votre métier, ou l’application ne sait plus faire ce qu’on lui demande : il faut écrire. Le plus souvent nous n’ajoutons pas de plateforme — nous construisons l’interface métier sur Power Apps et Dataverse, le socle natif de la Power Platform, avec une seule sécurité et des licences déjà acquises. Quand il faut du sur-mesure complet, nous l’écrivons : applications, portails, web services, traitements. Jamais en une seule livraison : par lots courts, chacun mis en production.

Retrait

La question est peut-être de l’éteindre.

Une application qui coûte cher à maintenir et dont l’arrêt ne gênerait personne n’a pas besoin d’être modernisée : elle a besoin d’être retirée proprement. Cela reste un travail — identifier les usages résiduels, conserver les données sous une forme lisible et interrogeable pendant la durée légale, prévenir les rares utilisateurs, éteindre le reste — mais c’est un travail de quelques semaines, pas un projet. Nous préférons vous le dire ici plutôt que de vous vendre autre chose.

La messagerie va vous lâcher avant le reste.

C’est la dépendance la plus dangereuse aujourd’hui, parce qu’elle est déjà datée. L’authentification de base pour l’envoi SMTP est retirée depuis le 30 avril 2026, et l’interface EWS d’Exchange Online se ferme par défaut le 1^er octobre 2026 pour disparaître en avril 2027. Une application qui envoie des messages ou lit des boîtes aux lettres doit passer à une authentification moderne, et à Microsoft Graph pour la lecture. Ce n’est pas une option de confort : c’est un compte à rebours.

Les interfaces invisibles décideront du calendrier.

Ce qui est branché à l’application n’est presque jamais documenté : le tableur d’un utilisateur qui lit la base en ODBC, le copieur qui dépose un fichier dans un partage, le script planifié sur un poste sous un bureau, l’export nocturne vers la comptabilité. Cela ne se trouve pas dans la documentation : cela se trouve dans les journaux et dans les flux réseau. Nous cherchons ces dépendances avant de chiffrer, parce qu’une seule oubliée déplace une bascule d’un mois.

C’est le cas le plus simple — et le plus souvent oublié.

Une application sans interface est la plus facile à déplacer : pas de contrat à renégocier avec un autre système, pas de fenêtre à coordonner. C’est aussi celle qu’on oublie dans un inventaire, précisément parce qu’elle ne parle à personne — jusqu’au jour où le serveur qui l’héberge est décommissionné et où un service découvre qu’il ne peut plus éditer ses documents. Nous vérifions donc d’abord qui l’utilise vraiment, et à quelle fréquence.

La reprise des données sera la moitié du travail.

Vingt ans de saisie sans contrainte, cela donne des doublons, des champs détournés de leur usage, des codes dont personne ne connaît plus la signification, et des dates au format libre. Nous mesurons le débit réel de reprise avant d’annoncer un calendrier, et si la mesure contredit le calendrier, c’est le calendrier qui change. La copie d’origine est conservée, chaque passage est rejouable, et la réconciliation se fait avec vos utilisateurs — pas avec un rapport technique.