Blog · Sortir de PCSOFT
Migration : la phase que tout le monde laisse hors périmètre
Depuis quelques semaines, des méthodes de reprise d'applications héritées circulent, assistées par IA. Elles sont sérieuses, et elles se ressemblent : on extrait du code, du schéma et des données de production une spécification écrite, domaine par domaine, règle par règle. J'ai déjà expliqué ici pourquoi la moulinette code à code est un mirage. Ces méthodes-là ne prétendent pas le contraire, et c'est tout à leur honneur.
Elles se terminent presque toutes par la même phrase : « phase 2, re-développement, hors périmètre ».
La parenthèse qui devrait vous alerter
Cette parenthèse contient l'essentiel du coût de votre projet, et la totalité de son risque. La phase 1 est la partie confortable : on lit, on synthétise, on rend des documents. La phase 2 est celle où quelqu'un s'engage sur un résultat qui marche un lundi matin, avec vos utilisateurs dedans.
Un prestataire qui vous vend la phase 1 vous vend la partie qu'il maîtrise, et vous laisse la partie qui fait mal. Ce n'est pas malhonnête. C'est simplement à vous de savoir où la ligne est tracée.
Une spécification reconstituée peut être fausse
C'est le point que je voudrais vous faire retenir, parce qu'il ne se voit pas.
Une spécification reconstituée à partir d'un code ancien se lit très bien. Elle est cohérente, elle paraît complète, et elle peut être fausse sans que personne s'en aperçoive, parce que la seule personne qui la relit est celle qui l'a écrite. Un document bien rédigé inspire une confiance qu'il n'a rien fait pour mériter.
Ces méthodes le savent, d'ailleurs. Elles produisent toutes une rubrique « points d'incertitude », et elles vous demandent de la valider. Ce n'est pas une note de bas de page : c'est le registre des risques de votre projet. Et en phase 2, chacune de ces incertitudes finira par être tranchée. Par quelqu'un, un mardi après-midi, sous contrainte de délai, sans que la décision soit écrite nulle part.
Trois ans plus tard, quand une remise ne se calcule plus comme avant, personne ne saura dire à quel moment ça a changé.
Ma règle tient en une phrase
Une règle extraite n'est pas adoptée tant qu'elle n'a pas été rejouée sur votre application existante.
Je joue le cas sur votre produit actuel, et je regarde ce qu'il fait. Pas ce que le code semble dire, pas ce que la notice affirme : ce qu'il fait. Une règle que je ne parviens pas à éprouver n'entre pas discrètement dans le nouveau produit. Elle repart en question chez vous, et quelqu'un tranche en connaissance de cause.
Cela coûte du temps, et c'est ce temps que vous payez. En échange, le nombre de ces questions devient mesurable, et tôt. Une application dont je sors quinze incertitudes et une application dont j'en sors deux cents ne se pilotent pas de la même façon, et il vaut mieux le savoir avant de s'engager qu'au troisième mois. C'est une bonne partie de ce que l'audit achète.
La même règle à la livraison
Un développement n'est pas vérifié en relisant du code. Il est vérifié en jouant ce qu'il promet.
Se connecter. Se déconnecter. Laisser une session expirer. Échouer une authentification. Tenter un accès auquel on n'a pas droit, et vérifier qu'on se le voit refuser. Les défauts sont là, pas dans une relecture attentive. Une relecture trouve ce qu'on a pensé à chercher ; l'exécution trouve ce qu'on n'avait pas prévu.
Pourquoi la connexion passe avant le métier
Dans l'ordre des travaux, je place le socle avant toute fonction métier : connexion, droits et rôles, sauvegardes et restauration, charte graphique.
Deux raisons. Le socle porte tout le reste, et le reprendre plus tard revient à refaire ce qui s'appuie dessus. Surtout, un défaut dans le socle est un défaut de sécurité, et un défaut de sécurité trouvé tard est trouvé par quelqu'un d'autre.
À la fin de cette étape, vous avez une application qui tourne, dans laquelle vos utilisateurs se connectent avec leurs droits, et qui ne fait encore aucun métier. C'est peu à regarder et c'est beaucoup à tenir.
Ensuite, un domaine fonctionnel à la fois, chacun mis en usage réel avant que le suivant commence. Un domaine livré mais pas utilisé ne prouve rien : tant que personne n'a saisi une vraie facture un jour de clôture, je ne sais pas si j'ai compris votre facturation. Je sais seulement que le code compile. Pendant tout ce temps, votre application actuelle continue de tourner.
Ce que je refuse de faire
Promettre l'iso-fonctionnel. Une application de vingt ans contient des écrans que personne n'ouvre, des options que personne n'active et des règles que personne ne sait expliquer. Tout reproduire coûte cher et fait entrer les défauts d'hier dans le produit de demain. Je vous dis ce que je trouve d'inutilisé, et vous décidez.
Chiffrer un périmètre que je n'ai pas mesuré. Un prix donné avant l'audit est une estimation déguisée en engagement.
Garder une règle que je ne sais pas expliquer. Elle repart en question chez vous. Si personne ne peut trancher, j'écris noir sur blanc qu'elle a été reconduite telle quelle sans être comprise. Vous saurez au moins où elle se trouve.
Réécrire un écran que je n'ai jamais vu servir.
La question à poser
Si vous consultez plusieurs prestataires dans les mois qui viennent, et vous aurez raison de le faire, la question utile n'est pas « comment produisez-vous la spécification ». Tout le monde saura y répondre, et de mieux en mieux.
La question est : comment savez-vous qu'elle est vraie ?
Et celle qui vient juste après : jusqu'où allez-vous avec moi ? Une méthode qui s'arrête avant le produit qui tourne vous laisse le plus difficile, et vous le découvrirez quand il sera trop tard pour changer d'avis.
Articles précédents : Migrer hors de WinDev : il n'y a pas de bouton magique · La grille se précise, 75, 100, 225