Votre application tourne en Rails 6 depuis des années. Elle fonctionne, elle rapporte, mais le framework n'est plus maintenu : plus de correctifs de sécurité, des gems qui refusent de s'installer, des développeurs qui grimacent devant le code. Tôt ou tard, il faut migrer de Rails 6 vers 7. La bonne nouvelle : ce n'est pas un big bang risqué. C'est un chemin par paliers, où chaque marche est testée avant de passer à la suivante.

Voici comment on procède chez Super Génial pour faire cette mise à niveau sans casser ce qui marche, et pourquoi la méthode compte plus que la vitesse.

Pourquoi on ne saute jamais plusieurs versions d'un coup

La tentation est réelle : partir de Rails 6.0 et viser directement Rails 7.1, en une seule bascule. C'est la meilleure façon de se retrouver avec une application qui ne démarre plus et une pile d'erreurs impossibles à démêler. Quand cent choses changent en même temps, vous ne savez plus laquelle a provoqué la panne.

Rails est conçu pour une montée progressive. Chaque version mineure introduit son lot de dépréciations : le framework vous prévient qu'un comportement va disparaître, avant de le supprimer réellement à la version suivante. Ces avertissements sont votre carte routière. En avançant palier par palier — 6.0 vers 6.1, puis 6.1 vers 7.0, puis 7.0 vers 7.1 — vous traitez les dépréciations une par une, pendant qu'elles ne sont que des messages dans les logs, pas des erreurs bloquantes.

Chaque palier suit le même rituel : on met à jour la version, on lance rails app:update pour régénérer les fichiers de configuration, on lit chaque diff proposé, et on ne passe au suivant qu'une fois la suite de tests entièrement verte. Un palier peut prendre une heure ou une journée. Mais on sait toujours exactement où on en est.

Le filet de tests : la condition avant de toucher au code

C'est le point non négociable. On ne migre pas une application sans filet de tests. Sans lui, chaque changement est un pari : vous modifiez la configuration, l'appli semble tourner, et trois semaines plus tard un client découvre que le tunnel de paiement est cassé depuis la migration.

Les tests automatisés transforment ce pari en certitude. Avant chaque palier, ils sont verts. Après, s'ils restent verts, vous savez que le comportement observable n'a pas changé. S'ils passent au rouge, ils pointent précisément la régression — dans le bon fichier, sur la bonne ligne.

Beaucoup d'applications héritées n'ont aucun test, ou si peu qu'ils ne couvrent rien d'utile. Dans ce cas, on ne fonce pas quand même : on pose d'abord des tests de non-régression sur les parcours critiques — connexion, paiement, formulaires clés, pages qui rapportent de l'argent. Pas une couverture exhaustive, mais un filet solide là où une panne coûterait cher. Ce travail préalable est souvent ce qui distingue une migration sereine d'un cauchemar. Nous l'intégrons systématiquement dans nos missions de reprise et maintenance.

Les changements notables entre Rails 6 et Rails 7

Trois évolutions demandent une attention particulière lors de cette mise à niveau.

Zeitwerk, le chargement des classes. Rails 6 tolérait encore l'ancien mode de chargement (classic). Rails 7 impose Zeitwerk, qui exige une correspondance stricte entre le nom de vos fichiers et celui de vos classes. Le moindre écart — un API là où Zeitwerk attend Api — bloque le démarrage. C'est justement pour cela qu'on active Zeitwerk dès le palier 6.x, quand il est encore optionnel : on règle le problème pendant qu'il n'est pas encore fatal.

Turbolinks devient Turbo. C'est le changement le plus visible côté front. Rails 7 remplace Turbolinks par Turbo, la brique centrale de Hotwire. Turbo ne se contente pas d'accélérer la navigation : il introduit les Turbo Frames et Turbo Streams, une nouvelle façon de mettre à jour des morceaux de page sans JavaScript maison. La migration turbolinks vers turbo n'est pas un simple renommage : certains comportements JavaScript existants doivent être réécrits, et il faut vérifier chaque interaction. On avance page par page, jamais en aveugle.

Les credentials chiffrés. Rails 7 consolide la gestion des secrets par environnement. Si votre application traîne encore d'anciens secrets.yml ou des variables éparpillées, c'est le moment de tout ranger dans les credentials chiffrés, versionnables sans exposer un seul mot de passe.

Une migration, ce n'est pas une réécriture

Le piège classique, quand on ouvre le capot d'une vieille application, c'est de vouloir tout refaire au passage : le design, l'architecture, cette partie du code qu'on trouve moche. On mélange alors deux chantiers, et on perd la seule chose qui rend une migration sûre : la capacité de dire « rien n'a changé sauf la version de Rails ».

La discipline, c'est de migrer d'abord, refactorer ensuite. Un palier ne doit changer que ce que la montée de version impose. Le reste — les améliorations, les nouvelles fonctionnalités — vient après, sur une base à jour et de nouveau maintenue.

C'est exactement le genre de chantier que nous menons à prix fixe : un diagnostic clair, un chemin par paliers, un filet de tests posé là où il manque, et une application qui repart sur une version soutenue. Si votre app est bloquée en Rails 6, parlons-en — commencez par notre offre de maintenance et remise à niveau, ou jetez un œil à nos tarifs et à d'autres ressources.