Comment utiliser l'IA pour accélérer une migration applicative sans perdre le contrôle de la qualité

Les assistants de code et les agents IA sont désormais capables de lire un module, de proposer sa réécriture et de générer des tests. Sur une migration applicative, où une grande part du travail est répétitive, c'est une aide réelle. C'est aussi une source d'erreurs nouvelles si on les laisse décider. Voici comment nous les employons : comme un accélérateur sous contrôle, jamais comme un pilote.

1. Ce qu'un modèle de langage fait bien

Lire et résumer du code inconnu. Expliquer ce que fait un contrôleur de 800 lignes, repérer les règles métier enfouies, proposer une carte des dépendances. Le gain sur la phase d'inventaire est net.
Proposer des refactorisations locales. Extraire une méthode, remplacer un appel déprécié, convertir des annotations en attributs, adapter une signature. Sur une classe isolée, les propositions sont souvent justes.
Écrire des tests de caractérisation. À partir d'un comportement observé (une requête et sa réponse, une fonction et ses sorties), rédiger le test qui le fige. C'est fastidieux pour un humain et rapide pour un modèle.
Produire de la documentation. Décrire un lot migré, expliquer un choix, rédiger un guide de déploiement.

2. Ce qu'il fait mal, ou dangereusement

Inventer. Une méthode qui n'existe pas dans cette version du framework, une option de configuration plausible mais fausse, un paquet Composer imaginaire. L'erreur est fluide, donc difficile à repérer à l'œil.
Changer le comportement en « améliorant ». Un modèle qui « nettoie » une condition étrange supprime parfois une règle métier volontaire. Les tests de caractérisation existent précisément pour attraper cela.
Raisonner sur tout le système. Au-delà de quelques fichiers, la cohérence se dégrade : noms incohérents, duplication, contrats d'interface rompus.
Évaluer le risque. Un modèle ne sait pas qu'un export mensuel est lu par un partenaire qui le charge tel quel ; il le reformatera volontiers.

3. Les garde-fous

Nous ne laissons une proposition d'IA entrer dans le code que si elle passe les mêmes barrières qu'une proposition humaine — et quelques-unes en plus.

| Garde-fou | Rôle | | --- | --- | | Tests de caractérisation avant tout | Figent le comportement actuel ; toute proposition qui les casse est rejetée, même si elle « a l'air mieux » | | Outils déterministes d'abord | Rector pour les réécritures mécaniques, PHPStan pour les erreurs de type : ce qui peut être fait par une règle n'est pas confié à un modèle | | Revue humaine systématique | Chaque diff proposé est lu par un ingénieur qui connaît le contexte ; pas de fusion automatique | | Petits lots | Une proposition = un périmètre lisible en une fois ; pas de « migre tout le module » | | Analyse statique après | PHPStan relancé après chaque lot, avec un niveau au moins égal à celui d'avant | | Journal des décisions | Ce que l'IA a proposé, ce qui a été accepté, modifié ou refusé, et pourquoi |

L'idée tient en une phrase : l'IA propose, les tests et l'ingénieur disposent.

4. La confidentialité du code et des données

Le code d'une application métier et, plus encore, ses données de production sont des actifs sensibles. Règles que nous appliquons et écrivons dans le cadrage :

Aucune donnée de production n'est transmise à un service d'IA. Les tests et les exemples sont construits sur des données synthétiques ou anonymisées.
Le choix du fournisseur et de l'hébergement du modèle est fait avec le client : service externe avec engagements contractuels de non-entraînement et de rétention nulle, ou modèle hébergé dans l'infrastructure du client quand le contexte l'exige.
Accord écrit avant toute transmission de code source, périmètre précisé (quels dépôts, quels fichiers exclus : secrets, configurations d'infrastructure).
Traçabilité : ce qui a été envoyé, quand, à quel service, pour quel lot.

Un client qui refuse tout usage de services externes n'est pas un obstacle : l'outillage déterministe (Rector, PHPStan, PHPUnit) fait déjà l'essentiel du gain, et des modèles locaux couvrent le reste.

5. Un déroulé type

Inventaire assisté : le modèle résume chaque module ; l'ingénieur valide et corrige la carte.
Tests de caractérisation : générés à partir de comportements observés, relus, exécutés ; ils deviennent le filet.
Réécriture mécanique par Rector ; analyse PHPStan.
Réécriture assistée des parties non mécaniques, fichier par fichier, chaque diff revu.
Tests + analyse statique ; mise en production du lot ; journal mis à jour.
Lot suivant.

Ce qu'il faut retenir

L'IA accélère l'inventaire, les refactorisations locales, les tests et la documentation.
Elle invente, modifie des comportements et ne mesure pas le risque : sans filet de tests ni revue, elle coûte plus qu'elle ne rapporte.
Les outils déterministes passent en premier ; le modèle traite ce qui reste.
La confidentialité se règle par contrat et par architecture, avant la première requête.

C'est l'approche décrite dans notre offre de modernisation PHP & Symfony : automatisation sous supervision, jamais migration automatique promise. Pour l'étape framework, voir migration Symfony 6.4 vers 7.4.

Sources : documentation Rector (getrector.com), PHPStan (phpstan.org), PHPUnit (phpunit.de) ; billet Symfony « Preparing for Symfony 7.4 and Symfony 8.0 » sur la détection des dépréciations (symfony.com/blog).