Votre application métier sert toujours à prendre des commandes, facturer ou organiser la production. Mais son développeur d’origine est parti, les mises à jour deviennent risquées et un prestataire propose une modernisation. Avant de comparer les prix, il faut savoir ce qui sera livré et comment vous pourrez l’accepter.
La modernisation applicative doit rendre un logiciel existant plus facile à maintenir et à faire évoluer, tout en préservant les règles métier encore utiles. Ce guide s’adresse au dirigeant de PME qui compare un devis. Il suit cinq étapes : audit, tests de référence, travaux maîtrisés, recette et maintenance. Une question les relie : les résultats métier satisfont-ils les critères convenus, ou les contrôles ont-ils changé pour rendre le rapport vert ?
L’essentiel en 60 secondes
- L’audit compare maintien, amélioration et remplacement. L’ancienneté ne suffit pas à choisir.
- Les parcours métier importants sont décrits et testés avant les travaux prévus. Protégez les tests de référence contre les modifications de l’agent réalisateur.
- Un secret exposé doit être révoqué ou remplacé immédiatement. La suite dépend des risques et des contraintes techniques.
- La recette vérifie les comportements convenus, les données, la reprise après incident et la passation. Les exceptions sont acceptées explicitement.
- Comparez ces livrables et les responsabilités dans chaque devis. Une ligne imprécise laisse le périmètre inconnu.
Avant de signer, demandez au prestataire de nommer le livrable d’audit, les parcours de référence, les travaux et la reprise prévus, les preuves de recette et le responsable de la maintenance. Ces cinq éléments rendent les devis comparables avant de discuter du prix total.
Dans cet article
- Auditer avant de choisir les travaux
- Décrire les comportements à préserver
- Modifier par étapes maîtrisées
- Faire la recette sur les preuves convenues
- Définir la maintenance avant la passation
1. Auditer avant de choisir les travaux
L’audit établit ce qui fonctionne, ce qui en dépend, les incidents qui comptent et qui détient les accès. Demandez l’inventaire des versions et bibliothèques, les vulnérabilités connues, le déploiement, les sauvegardes et les connexions critiques. Le logiciel peut réussir ses tests alors que la liaison avec la facturation échoue.
Le statut de support se vérifie dans le calendrier du projet, comme celui de Node.js. La fin de vie arrête sa maintenance habituelle ; un éventuel support commercial prolongé se vérifie séparément. Une dépendance jamais analysée est une inconnue, pas la preuve d’une faille particulière.
Hiérarchisez les constats selon leur impact métier, distinguez les mesures urgentes et comparez les options : améliorer l’existant, remplacer un module, adopter un produit du marché ou réécrire. Le choix dépend du besoin métier, de la maintenabilité, du risque de transition et du coût de préservation des comportements. Un nouveau modèle de données est un critère parmi d’autres.
Même si l’audit recommande peu de travaux, ses constats, options et périmètre délimité doivent rester utiles. Notre guide sur la dette technique traite le choix entre refactorisation, réécriture et maintien.
2. Décrire les comportements à préserver
Quand tests ou spécifications manquent, les tests de caractérisation enregistrent ce que fait le code. Ils ne prouvent pas que ce comportement est juste. Le responsable métier distingue ce qu’il faut conserver, les défauts connus et les changements voulus.
Retenez des parcours concrets : calculer une facture, rembourser, exporter ou autoriser l’accès à un dossier. Précisez les entrées, les résultats attendus et qui tranche une ambiguïté. Si le format d’une facture change, exigez l’équivalence des valeurs convenues, pas nécessairement un PDF identique.
Les tests utilisent un environnement séparé et des données représentatives fictives ou anonymisées. La CNIL prévoit une exception en préproduction lorsque ces données ne suffisent pas : les tests préalables doivent avoir été réalisés et la sécurité doit être équivalente à celle de la production. Décidez du traitement des données avant toute copie.
Identifiez la version du jeu de tests, documentez son exécution et désignez un responsable. Les failles font l’objet de contrôles distincts dans un environnement autorisé. Convenez des vérifications avant de modifier un parcours critique. Une protection urgente nécessite une validation proportionnée, sans attendre le jeu complet.
3. Modifier par étapes maîtrisées
Un accès compromis se traite immédiatement. La documentation GitHub commence par révoquer ou remplacer le secret exposé ; nettoyer l’historique du dépôt est une opération distincte. La montée de version ne doit pas retarder cette protection.
L’audit guide l’ordre des travaux : une dépendance peut exiger un environnement plus récent ; une logique imbriquée peut nécessiter une isolation préalable. Prévoyez supervision et reprise assez tôt, puis livrez des lots que le relecteur peut examiner.
Chaque lot précise son objectif, les parcours concernés, les contrôles et la procédure de reprise. Fixez les versions des dépendances et documentez l’environnement de construction : une version supportée ne suffit pas à rendre la compilation reproductible. Précisez les rapprochements de données, les enregistrements en attente et la reprise. Restaurer l’ancien code n’annule pas automatiquement une migration.
Les correctifs de sécurité demandent leurs critères de recette. Un changement du stockage des mots de passe doit prévoir le traitement des hachages existants, des comptes non reconnectés et des réinitialisations. Le guide OWASP décrit les mises à niveau possibles ; choisir l’algorithme ne règle pas tout.
Où interviennent les outils d’IA ?
AWS Transform custom documente analyse, transformation et commandes de validation. GitHub Copilot modernization décrit évaluation, planification, mises à niveau et validation des tests pour les technologies prises en charge. Ces outils interviennent à plusieurs étapes.
Ces capacités ne donnent pas un délai ni un résultat établis pour votre application. Demandez quelles fonctions s’appliquent à votre application, comment elles seront contrôlées et qui validera le résultat. Une tâche non documentée n’est pas nécessairement impossible.
Comment IZZY sépare réalisation et vérification
La règle de travail IZZY sépare réalisation et vérification. Un orchestrateur répartit le travail entre les agents ; le réalisateur n’est pas autorisé à modifier les tests qui vérifient ses changements. Un autre agent, avec un modèle d’un fournisseur différent et un accès en lecture seule, relit le résultat. Le nombre d’avis augmente avec la criticité.
Deux fournisseurs peuvent partager une erreur. Confrontez les remarques aux preuves de recette convenues : l’accord des agents ne suffit pas à établir que l’application répond aux critères. Notre cadre de contrôle des agents détaille les limites de ce qu’un agent peut modifier et démontrer.
Dans le dernier code produit par IA que nous avons repris, le premier vrai défaut est apparu en production. Cette observation isolée explique notre attention aux comportements réellement contrôlés ; elle ne mesure aucun taux d’échec.
Dans notre dépôt public Linkrypt, cinq cas de référence rendent consultables des entrées nommées et des sorties attendues fixées. C’est le détail à demander au prestataire : une référence identifiable et comparable. Linkrypt est un exemple de produit, pas un cas client de modernisation.
Un rapport vert avec un total faux
Prenons un calcul hypothétique, sans lien avec un projet réel. Trois montants de 10 000, 2 500 et 750 centimes doivent donner 13 250 centimes. Supposons qu’un remplacement omette le dernier montant et retourne 12 500. Si le résultat attendu devient lui aussi 12 500, le contrôle passe alors que le calcul reste faux. La référence initiale signalerait toujours l’échec.
Demandez au prestataire : « Avez-vous corrigé le calcul ou changé le résultat attendu ? » Réclamez la référence initiale, la version de l’application et l’explication des écarts. Si la règle métier évolue, approuvez-la explicitement et faites relire ses contrôles révisés séparément.
Un seul exemple protégé ne couvre pas toute une application. Faites examiner des entrées représentatives et le code modifié par le relecteur technique. Une empreinte numérique révèle une différence ; elle n’empêche pas les modifications et ne prouve pas que la référence initiale était juste.
4. Faire la recette sur les preuves convenues
Rejouez les contrôles et comparez les résultats significatifs. Examinez les écarts ; le responsable métier valide les changements voulus. Revérifiez les constats de sécurité dans le périmètre testé, puis répétez restauration et reprise sur la nouvelle installation. Comparez les performances des parcours importants à une référence convenue.
| Livrable à la recette | Ce qu’il établit | Ce qu’il n’établit pas encore |
|---|---|---|
| Accès au dépôt, à l’hébergement et à la chaîne d’intégration continue (CI), identifiants de déploiement nécessaires détenus par le propriétaire | Le propriétaire détient les accès et identifiants listés | Que son équipe a répété le déploiement |
| Tests de référence versionnés, version de l’application testée, procédure et résultats datés | Les contrôles convenus et leurs résultats consignés | La couverture de toutes les pannes possibles |
| Constats d’audit corrigés, acceptés ou reportés | Les points traités et les risques restants | Qui traite les reports, sans responsable nommé |
| Migrations de données achevées ou en attente | Les enregistrements rapprochés et ceux qui restent | Que chaque migration restante finira automatiquement |
| Calendrier de support et rythme des mises à jour | Les échéances connues et les revues prévues | Qui réalise le travail, sans attribution explicite |
Gardez ce tableau avec le procès-verbal de recette. Chaque report nécessite un responsable, une date de revue et une acceptation explicite du risque. Détenir les accès ne suffit pas : vérifiez que l’équipe repreneuse sait les utiliser. Notre guide de passation d’une base de code détaille ce transfert.
5. Définir la maintenance avant la passation
Convenez de qui reçoit les alertes, applique les correctifs et gère les incidents. Listez prestations incluses, délais d’intervention, exclusions, comptes rendus et décision à l’échéance. Une correction de défaut et une nouvelle fonctionnalité ne doivent pas être confondues dans le contrat.
Cadrez les tâches restantes et leurs responsables. Toute poursuite de maintenance demande un accord distinct.
Que doit contenir un devis de modernisation applicative ?
Le devis doit relier les cinq étapes à des livrables et responsables nommés : constats et options d’audit, tests de référence, travaux et reprise, preuves de recette, puis maintenance. Choisissez un parcours que vous connaissez, comme la facturation, et demandez à chaque prestataire de le suivre dans ces livrables. Voici une formulation à demander, pas un exemple client :
Avant les travaux, enregistrer et faire approuver le calcul de référence. Protéger ses tests contre les modifications de l’agent réalisateur. Pour la recette, fournir les versions de l’application et des tests, les résultats, les écarts expliqués et une relecture distincte. Nommer qui accepte une modification de la référence.
Lisez la réponse pour décider :
- Clarifier : « modernisation, tests inclus » laisse les parcours, les preuves ou les responsabilités imprécis. Demandez ces informations sans supposer qu’elles sont exclues.
- Suspendre la validation : un résultat critique diffère sans explication, ou un test modifié masque l’échec. Tranchez le comportement attendu et faites relire le contrôle.
- Accepter le lot délimité : les critères de recette sont satisfaits, ou les exceptions documentées ont été explicitement acceptées par le responsable, et l’équipe sait utiliser les livrables. Cette décision concerne ce périmètre, pas toutes les propriétés possibles du logiciel.
Utilisez le calcul hypothétique pour discuter des preuves avec le prestataire. Un rapport devenu vert après modification du résultat attendu appelle une clarification, pas une validation automatique.
Apportez-nous l’application et le devis
Commencez par le devis et un parcours métier à préserver. Notre service Missions de sauvetage et durcissement de code IA audite les applications reprises et cadre une remise en état progressive. Pour l’évaluation technique, convenez des accès au dépôt et des informations d’hébergement nécessaires. Le devis porte sur un périmètre convenu ; les nouveaux travaux sont cadrés séparément.
Questions fréquentes
Quand sa valeur métier et sa maintenabilité justifient le coût et le risque de transition face aux autres options. Lorsque le contexte le permet, le remplacement progressif fait évoluer les parties pendant que l’existant continue de fonctionner.
Oui. Confrontez les résultats attendus aux règles métier. Protégez les contrôles contre les modifications de l’agent réalisateur ; faites relire séparément les changements autorisés de référence. Des tests générés qui passent ne suffisent pas à établir la justesse.
Demandez une estimation liée au périmètre audité, aux intégrations, aux tests, aux données et à la recette. Précisez les inconnues et les points de réévaluation. Une démonstration d’outil ne constitue pas votre calendrier.
Associez-le à la cartographie des dépendances et à l’explication des comportements inhabituels. Le responsable métier confirme les règles encore utiles. Consignez-les pour qu’elles survivent à une nouvelle passation.
Sources et limites
Sources techniques relues le 16 octobre 2026. Les erreurs partagées entre modèles et les résultats variables de relecture invitent à la prudence face à leur accord ; ces études ne valident pas l’approche IZZY. ImpossibleBench observe des contournements sur des tâches volontairement contradictoires, sans mesurer les échecs des projets ordinaires. Son dépôt signale un défaut d’implémentation ultérieur ; aucune réplication n’est revendiquée. Linkrypt a été inspecté à la version liée, sans nouvelle exécution de tous ses tests ni audit de sécurité. Le calcul et la formulation du devis sont illustratifs. La CNIL concerne le contexte français. Les déclarations du 13 octobre étayent la règle et l’observation IZZY. Aucun outil de transformation n’a été comparé expérimentalement.