Quand j’ai commencé mon alternance chez Sopra Steria sur un système d’information fiscal utilisé à grande échelle, je m’attendais à du code. Beaucoup de code. Et à passer mon temps à en écrire.
Ce n’est pas ce qui s’est passé. Et c’est tant mieux.
Pendant mes premiers mois, j’ai surtout passé du temps à lire. Lire du code que je n’avais pas écrit. Lire des configurations dont je ne comprenais pas la moitié. Lire des tickets fermés depuis trois ans pour reconstituer pourquoi telle fonction faisait telle chose. Lire le Wiki, parfois pour me rendre compte que la moitié n’était plus à jour.
Au début, j’ai cru que c’était une période transitoire. Que dans deux mois, je « commencerais à coder vraiment ». Puis j’ai compris que cette période, c’était ça, le travail. Lire pour comprendre. Comprendre pour ne pas casser.
Cet article rassemble ce que personne ne m’avait dit avant cette alternance, et que j’aurais bien aimé entendre.
Le legacy, ce n’est pas le code
Le mot « legacy » fait peur. Quand tu es étudiant, tu l’entends souvent prononcé avec une grimace : « ah, du legacy », comme on dirait « ah, une grippe ». Tu imagines du Java 6, des controllers de quatre mille lignes, des tests qui ne passent plus depuis 2014.
Parfois c’est vrai. Mais ce n’est pas ça, le vrai problème. Le vrai problème du legacy, ce n’est pas le code. C’est le contexte autour du code.
Sur un projet greenfield (un projet neuf), le contexte est mince. Tu construis. Tu décides. Tu peux te tromper en local et corriger demain. Le risque est faible parce que personne n’utilise encore vraiment ce que tu fais.
Sur un legacy, le contexte est dense. Le code que tu touches est utilisé à grande échelle, par des gens qui ne pardonnent pas un dimanche soir cassé. Il y a des invariants implicites partout : des choses que personne n’a documentées parce que « tout le monde le sait ». Il y a des décisions techniques prises il y a dix ans pour des raisons qui ont peut-être disparu, mais dont tu ne peux pas être sûr. Il y a des dépendances entre modules dont tu ne soupçonnes l’existence qu’au moment où tu les casses.
Tu n’écris pas du code. Tu écris dans un système.
Cette nuance change tout.
Ce qui marche
Lire avant d’agir
C’est le réflexe le plus important et le plus difficile à acquérir, parce qu’il va contre l’instinct étudiant. À l’école, tu es noté sur ce que tu produis. En entreprise sur un legacy, tu peux passer une journée entière à lire et à ne rien produire de visible, et c’est une excellente journée.
Quand on me confie un ticket, je lis le code concerné en premier. Pas pour comprendre l’algorithme, souvent il est simple. Pour comprendre où il est appelé, par quoi, avec quelles données possibles. Le code en lui-même est rarement le problème. Le problème est presque toujours dans les bords : l’appelant qui passe une donnée inattendue, le configurateur qui a oublié de mettre à jour un paramètre, le batch qui tourne à deux heures du matin et que tu ne vois jamais.
Cartographier les dépendances avant de toucher
Avant de modifier une méthode, je trace mentalement (ou parfois sur papier) ce qui en dépend. Quels appelants ? Quels tests ? Quelles configurations ? Cette carte est presque toujours plus large que ce que je pensais.
Ce réflexe simple m’a évité plus d’une fois de casser des choses que je n’avais pas vues.
Demander pourquoi avant comment
Quand tu reprends un code, le « comment » est dans le code. Le « pourquoi » est dans la tête de la personne qui l’a écrit, et cette personne n’est souvent plus dans l’équipe. Avant de modifier une logique étrange, vaut le coup de poser la question : « pourquoi est-ce fait comme ça ? ».
Parfois la réponse est « personne ne sait, on peut nettoyer ». Mais souvent la réponse est « parce qu’en 2019 il y a eu un incident où… », et là tu comprends que cette ligne bizarre, c’est la cicatrice d’une bataille que personne n’a envie de refaire.
Assumer que tu ne comprends pas le 80 % caché
Quand j’arrive sur un module, je sais peut-être 20 % de ce qui le fait fonctionner. Le reste est implicite, distribué dans d’autres modules, ou dans le contexte projet. Cette humilité m’a beaucoup servi. Elle ne veut pas dire « ne fais rien ». Elle veut dire « touche petit, vérifie souvent, ne suppose jamais ».
Tracer ce que tu fais
Sur un legacy, ce que tu fais sera relu, repris, et sans doute critiqué (à raison) plus tard. Documenter ses changements, pas en détail mais en intention, est un cadeau qu’on fait à soi-même dans six mois, et à l’équipe dans deux ans. Un commit propre, un commentaire de PR clair, une mise à jour Wiki quand le change le mérite. Trois petits gestes, gros effet cumulatif.
Ce qui ne marche pas
Vouloir tout refactoriser
C’est la tentation numéro un de l’alternant. Tu lis du code que tu trouves moche. Tu te dis « je vais nettoyer ça ». Mauvaise idée, presque toujours.
Ce code « moche » a des contraintes que tu ne vois pas encore. Il fonctionne, parfois depuis des années. Le refactoriser, c’est introduire du risque pour un gain esthétique. Sur un projet client à fortes contraintes, ce trade ne vaut pas le coup. La règle saine : tu refactorises seulement quand tu dois modifier quelque chose, jamais juste parce que tu peux.
Croire à la documentation à la lettre
La documentation est un instantané. Le code est la vérité du moment. Quand les deux divergent, le code gagne, parce que c’est lui qui tourne en production.
Lis la documentation pour avoir une intuition générale. Vérifie systématiquement dans le code que ce que tu lis est encore vrai.
Se reposer sur les tests existants
Sur un legacy, les tests existants ne couvrent pas forcément ce que tu crois qu’ils couvrent. Certains testent des comportements qui n’existent plus. D’autres ont été écrits autour d’un bug pour le contourner. D’autres encore passent par hasard.
Avant de te dire « je suis tranquille, le test passe », lis le test. Comprends ce qu’il vérifie vraiment. Et ajoute le tien si la couverture sur ton change est mince.
Sous-estimer les invariants implicites
Sur un système qui tourne depuis longtemps, il y a des règles implicites partout. « Cette table n’est jamais vide en production. » « Ce flag est toujours à vrai sauf en cas de batch X. » « Ce paramètre n’est jamais à zéro. » Ces règles ne sont pas écrites. Elles sont dans la tête de quelqu’un, ou elles ont été oubliées.
Quand tu écris un nouveau cas, demande-toi : « qu’est-ce que ce code suppose de l’environnement, et est-ce que cette supposition est vraiment vraie ? ». Le pire est l’invariant qui était vrai et qui ne l’est plus depuis trois mois.
Confondre comprendre le code et comprendre le système
C’est la confusion la plus dangereuse. Tu peux comprendre parfaitement une méthode, savoir ce qu’elle fait ligne à ligne, et n’avoir aucune idée de ce que le système autour fait. C’est très différent. Le code, c’est la mécanique. Le système, c’est la mécanique plus le contexte d’usage, plus les batchs autour, plus les configurations qui changent selon l’environnement, plus les dépendances métier.
Comprendre le système prend des mois. Comprendre une méthode prend une heure. Ne mélange pas les deux.
Le piège mental dont personne ne parle
Voilà la partie que personne ne m’avait dite, et qui aurait probablement été utile.
Travailler sur un legacy, en alternance, ça t’use intérieurement d’une manière que tu n’as pas vue venir.
Tu produis peu de visible. Tes journées sont remplies de lecture, de questions, de petits changements prudents, de validations longues. À côté de toi, tu vois des amis qui codent en greenfield, qui shippent des features, qui ont des trucs à montrer sur LinkedIn.
Toi, tu as ajouté trois lignes ce mois-ci. Tu es en train de comprendre une méthode. Tu fais ce qu’il faut, mais ça ne se voit pas.
C’est là qu’apparaît un sentiment piège : la sensation d’être lent, mou, de ne pas progresser. Le syndrome du « j’apprends à pas casser plutôt qu’à construire ». Ça génère de la frustration, surtout si ton manager ne reconnaît pas explicitement ce travail invisible.
Ce que je me dis maintenant, et qui m’aide :
Tu n’apprends pas à coder. Tu apprends à intervenir. Ce n’est pas la même chose, et ce n’est pas moins important.
Coder, c’est produire du nouveau. Intervenir, c’est modifier de l’existant sans le casser. Beaucoup de gens savent coder. Bien moins savent intervenir. C’est une compétence rare, plus rare que ne le suggèrent les offres d’emploi, parce qu’elle ne se mesure pas en lignes ajoutées mais en bugs évités.
Si tu es alternant sur un legacy et que tu ressens ce piège mental, ce n’est pas que tu progresses mal. C’est que la nature de ce que tu apprends ne se montre pas naturellement.
Ce que tu gagnes vraiment
Quand je prends du recul sur ce que cette année m’a donné, ce n’est pas du tout ce à quoi je m’attendais.
La maîtrise du risque. Avant de toucher quoi que ce soit, je me demande maintenant ce qui peut casser. Cette pensée n’était pas naturelle pour moi à l’école. Elle l’est devenue.
La lecture rapide d’un code que je n’ai pas écrit. Je ne suis pas encore expert, mais je peux entrer dans un module inconnu et avoir une intuition de son rôle en trente minutes. C’est une compétence qu’on utilise chaque jour de sa vie professionnelle, et qu’on enseigne très peu.
La capacité à dire « je ne sais pas encore ». Sur un legacy, faire semblant est dangereux. J’ai appris à dire « je ne sais pas encore, je vais vérifier » sans paniquer. Cette habitude vaut beaucoup plus que je ne le pensais.
L’habitude de la rigueur. Pas la rigueur étudiante (faire les choses parfaitement du premier coup), mais la rigueur d’ingénieur (vérifier deux fois avant de pousser, tracer ses changes, anticiper le pire cas). Cette rigueur ne s’apprend pas en cours, elle s’apprend par l’exposition au risque réel.
Une humilité technique solide. Je sors de cette alternance moins sûr de moi qu’avant, pas dans le mauvais sens. Avant, je pensais que comprendre un langage suffisait. Maintenant je sais qu’un système est un être complexe, vivant, partiellement incompréhensible, et que le respecter est une partie centrale du métier.
Conclusion
Le legacy est une école sévère. On y apprend lentement, sans applaudissements, en passant des heures à lire pour ajouter trois lignes le lendemain.
Mais ce qu’on y apprend dure. Les compétences acquises sur un système existant en production, à fortes contraintes, sont parmi les plus universelles et les plus transférables du métier d’ingénieur logiciel. Elles ne se voient pas sur un CV, mais elles se sentent dans la première PR.
Si tu es étudiant et qu’on te propose une alternance sur du legacy, ne fais pas la tête. C’est probablement plus formateur qu’un greenfield.
Si tu es alternant en plein milieu de cette traversée, et que tu sens ce piège mental de la lenteur invisible : ce n’est pas un signal de stagnation. C’est le bruit de fond d’un apprentissage qui ne se montre pas encore.
Continue à lire avant d’agir. Continue à demander pourquoi. Continue à tracer tes changes. Et donne-toi le temps de devenir, dans le calme, le genre d’ingénieur dont les équipes ont vraiment besoin.