L’attrait des nouvelles technologies
J’ai toujours eu de la difficulté à décider s’il faut adopter une nouvelle technologie. J’aime essayer des outils tôt, souvent pendant qu’ils sont encore en bêta. Quand quelque chose me plaît, je commence vite à voir dans quels autres contextes ça pourrait s’appliquer.
En même temps, je sais que le choix le plus prudent est souvent d’attendre, ou de limiter l’adoption à un projet interne où l’impact client reste faible. Cette tension m’accompagne depuis des années.
Comment on s’est retrouvés avec quatre piles
Avec le temps, j’ai vu le même schéma revenir dans plusieurs initiatives. On repérait une vraie douleur dans le système en place, on choisissait une pile qui semblait meilleure, puis on lançait la migration avec de bonnes intentions. La partie la plus difficile n’était presque jamais de décider de changer. C’était de finir une fois que les priorités avaient bougé.
Comme bien des entreprises, on a regardé notre monolithe et conclu qu’il était devenu trop gros pour être maintenu confortablement. On a extrait des services et on a commencé avec Laravel parce que notre base existante était en PHP. Les premiers services se sont bien passés, puis le travail d’affaires urgent a pris le dessus et la migration s’est mise en pause.
Quand on y est revenus, la migration vers le cloud était devenue centrale. À ce moment-là, PHP dans Lambda était moins simple qu’aujourd’hui, alors une partie de l’équipe a déplacé de nouveaux services vers Golang. Ce virage s’est aussi essoufflé. Il y a eu des réorganisations, des départs, et éventuellement très peu d’ingénieurs se sentaient encore à l’aise pour maintenir des services Go. On a ensuite basculé encore une fois vers Node.js, parce que ça cadrait mieux avec les forces de l’équipe et la réalité du recrutement.
Près de dix ans plus tard, le monolithe est toujours en production, avec des services répartis entre Laravel, Golang et Node.js. Aucune de ces technologies n’est le problème en soi. Le poids vient du fait de devoir porter tout ça en même temps.
Ce qu’on a manqué dans la migration
Avec le recul, je pense qu’on a sous-estimé le coût et la durée d’une migration à cette échelle. Je croyais que la grande décision consistait surtout à choisir la bonne pile cible. Avec le temps, j’ai commencé à voir que la continuité de la migration compte plus que le choix initial.
Dans les faits, on aurait peut-être gagné davantage en rendant d’abord le monolithe plus facile à faire évoluer : des frontières plus claires, une meilleure séparation des responsabilités et une structure interne plus modulaire avant d’extraire quoi que ce soit.
On changeait aussi de technologie trop souvent. Les choix de pile ne sont pas seulement une question de capacités aujourd’hui. Ils concernent aussi la capacité de l’équipe à les soutenir sur cinq ans, la possibilité d’embaucher autour de ces choix et le fait que la responsabilité opérationnelle reste réaliste.
L’IA change la mécanique, pas les questions
L’IA enlève quand même une partie de la friction. Comprendre du code dans une autre langue de programmation va plus vite qu’avant, surtout quand les bases en ingénierie sont solides. C’est plus simple de lire des services moins familiers, de migrer avec de l’aide et de déboguer dans plusieurs piles.
Par contre, l’IA n’enlève pas la complexité architecturale. Elle n’enlève pas non plus le coût opérationnel de faire rouler plusieurs piles en production. Elle ne remplace pas la nécessité d’être clair sur la raison d’une migration dès le départ.
Si je devais prendre cette décision à nouveau, je ralentirais et je testerais les bases : quel problème on essaie vraiment de régler, si la migration enlève réellement cette contrainte, combien de temps il faudra avant de voir une amélioration concrète, et à quel moment on arrête si la valeur n’arrive pas.
Le but, c’est de simplifier ce qu’on doit opérer, pas d’accumuler plus d’options qu’on peut en soutenir. Il n’y a pas de solution miracle ici. Plusieurs piles peuvent résoudre le même problème. La vraie question, c’est de savoir quelle option s’agence le mieux avec notre contexte, la capacité de l’équipe et les contraintes à long terme.
Si cet équilibre change plus tard, la migration peut quand même être le bon choix. Mais il faut un vrai plan, un échéancier réaliste et la discipline de terminer. Sans cette continuité, on finit avec un ensemble de décisions raisonnables qui deviennent lourdes une fois combinées.
- Patrick