À un moment donné, écrire du code cesse d'être la partie difficile

Pendant longtemps, j'ai mesuré ma progression à ce que j'étais capable de construire. Un nouveau framework appris, un nouveau type d'app livré, une ligne de plus dans la section stack de mon CV. Ça ressemblait au bon tableau de score, parce qu'au début, c'était à peu près le cas.

Ce que je n'ai pas remarqué, c'est le moment où le tableau de score a cessé de refléter la partie. Le code n'est pas vraiment devenu plus facile. Il a simplement cessé d'être ce qui m'empêchait de dormir. La difficulté s'était déplacée ailleurs : décider quoi construire, décider quoi ne pas construire, et vivre avec les conséquences des deux.

Cet article est une tentative de décrire ce changement tel que je l'ai vécu. Ce n'est pas une grille pour décider qui est senior. Les titres ne veulent pas dire la même chose d'une entreprise à l'autre, ni d'un marché à l'autre. En 2025, j'étais Software Engineer dans une entreprise et Senior Software Engineer dans une autre, en même temps, puis quelques mois plus tard Full Stack Developer dans une troisième. Le travail derrière ces titres était bien moins différent que les mots. Lisez donc ceci comme le regard d'un ingénieur sur la façon dont les problèmes ont changé, pas comme une échelle que tout le monde devrait gravir.

Junior : apprendre à exécuter

J'ai commencé en 2022, en prototypant une app de livraison, web et mobile, alors que j'étais encore étudiant. J'étais seul dessus, ce qui voulait dire que je prenais toutes les décisions : l'architecture, le modèle de données, la façon dont les pièces communiquaient. Pendant un temps, j'y ai vu le signe que j'étais plus avancé que je ne l'étais réellement.

Il m'a fallu des années pour comprendre la différence. Prendre des décisions que personne ne relit, ce n'est pas la même chose que prendre de bonnes décisions. Personne ne me disait qu'un choix était mauvais, alors je supposais qu'il ne l'était pas. Je prenais des décisions d'architecture sans savoir quelles étaient les alternatives, ce qu'elles coûtaient, ni ce qui allait casser six mois plus tard. Je ne savais pas ce que je ne savais pas.

Quand j'ai rejoint une équipe en 2024, sur des apps web et mobiles en React, Next.js, React Native et Flutter, la forme de mon travail est devenue plus claire, et honnêtement plus confortable. Les tâches arrivaient bien définies. Quelqu'un avait déjà décidé ce que l'écran devait faire ; mon travail était de le lui faire faire. La question que je me posais toute la journée était :

« Comment est-ce que j'implémente ça ? »

Ce n'est pas une petite question. À ce stade, c'est la bonne. On apprend la stack, la base de code, les conventions que personne n'a écrites, et la différence entre du code qui marche sur sa machine et du code qui survit à la review. J'avais souvent besoin d'être guidé, et j'avais besoin que ce soit précis.

Avec le recul, ce que je construisais surtout, ce n'étaient pas des features. C'était l'exécution : la capacité de prendre quelque chose de défini et d'en faire un logiciel qui fonctionne, sans drame. Tout ce qui est venu ensuite en dépend. On ne peut pas raisonner sur des trade-offs dans un code qu'on a encore du mal à écrire.

Mid-level : apprendre à porter

Le passage à mid-level n'est pas venu avec un nouveau type de tâche. Il est venu avec moins d'instructions autour du même type de tâche.

Au lieu de « construis cet écran », c'est devenu « on a besoin de cette intégration ». J'ai travaillé sur des intégrations avec Mercado Livre, Shopee et Meta, et j'étais responsable de la publication et de la maintenance d'apps iOS via Apple Developer : le cycle de release, les règles de validation de l'App Store, la partie du travail qui commence après le merge de la pull request. Cette dernière partie m'a appris quelque chose que le code ne m'avait jamais appris. Une feature n'est pas finie quand elle fonctionne. Elle est finie quand elle est entre les mains des utilisateurs et qu'elle fonctionne toujours.

Les systèmes externes vous imposent cette leçon. Leurs API tombent en timeout, changent sans prévenir, envoient le même événement deux fois ou répondent avec succès alors que la moitié des données manque. Alors les questions que je me posais ont commencé à changer. Que se passe-t-il quand cet appel échoue ? Et si ce webhook arrive deux fois ? Comment tester ça sans débiter une vraie carte ? Comment saurai-je que ça a cassé en production avant qu'un client me le dise ?

La question sous-jacente à toutes celles-là était :

« Quelle est la meilleure façon de résoudre ça ? »

Cette question suppose que le problème est déjà le bon. Quelqu'un d'autre a décidé ce qu'on résout ; moi, je décide comment. Je suis devenu responsable des edge cases, des tests, de la performance et des déploiements, et j'avais besoin de moins en moins de détails dans le ticket pour livrer.

C'est une vraie étape, et pendant un temps elle ressemble au métier tout entier. On vous fait confiance. Vous livrez. Les gens arrêtent de vérifier chaque ligne. Il est facile de croire que l'étape suivante, c'est simplement plus de la même chose : des features plus grosses, des systèmes plus complexes, plus de technologies.

Pour moi, ça ne l'a pas été.

Senior : apprendre à décider

Le signe le plus clair que mon travail avait changé, c'est que j'ai commencé à recevoir des problèmes plutôt que des tâches.

Pas « construis X », mais « cet écran est lent », « ce système doit sortir de Firestore », « les clients n'arrivent pas à payer et on ne sait pas pourquoi ». Pas de spécification, parfois pas de responsable clair, et souvent une information incomplète sur ce qui se passait réellement.

De nouveaux problèmes

Les problèmes eux-mêmes ont changé de forme. Ils portaient moins souvent sur une feature, et plus souvent sur un système déjà en production, dont des gens dépendaient.

Un ERP centré sur la gestion de flotte, sur lequel j'ai travaillé, devait migrer son cœur de Firestore vers PostgreSQL, et six produits distincts devaient être consolidés en un seul déploiement multi-tenant. La contrainte qui a tout façonné, c'est que l'activité ne pouvait pas s'arrêter. Écrire le nouveau schéma n'était pas la partie difficile. La partie difficile, c'était de décider comment migrer module par module, ce qui pouvait coexister et pendant combien de temps, et quel risque on acceptait à chaque étape. Rien de tout ça ne tient dans un ticket.

De nouvelles responsabilités

Les responsabilités ont changé aussi, et elles étaient plus difficiles à remarquer, parce que personne ne vous les donne dans un ticket.

Ce qui se passe après le déploiement. Sur un produit web et mobile utilisé par des milliers de personnes, être responsable voulait dire crash reporting, logs et métriques : savoir que quelque chose a cassé avant qu'un client vous le dise.
L'argent et les données des autres. Paiements et webhooks, où le même événement peut arriver deux fois et où un retry imprudent débite quelqu'un une seconde fois. Et décider quoi ne pas collecter : dans un flux de paiement, ce qu'on a laissé hors de l'instrumentation a compté autant que ce qu'on a capturé.
Traduire les trade-offs. Expliquer à des gens qui ne lisent pas de code à quoi on renonce, pourquoi, et ce que ça coûtera plus tard.
Construire moins. Se demander si la feature demandée résout le problème, et parfois plaider pour ne pas la construire.
Assumer la décision. Trancher sans que quelqu'un valide chaque étape, et l'assumer quand elle s'avère fausse.

C'est en construisant à nouveau un produit de zéro que la différence m'est apparue clairement. En 2022, seul sur l'app de livraison, je prenais toutes les décisions et personne n'en payait aucune. En construisant de zéro une plateforme multi-tenant d'automatisation de marketplace, avec intégrations, paiements et flux de commandes, je prenais à nouveau la plupart des décisions. L'autonomie était la même. Le poids était complètement différent : de l'autre côté de chaque décision, il y avait des clients qui payaient.

Alors la question a changé à nouveau :

« Quel problème essaie-t-on vraiment de résoudre ? »

Cette question est inconfortable. Parfois la réponse, c'est que la feature demandée ne résout pas le problème de la personne qui l'a demandée. Parfois, c'est « je ne sais pas encore, et voilà comment on va le découvrir ». Dans tous les cas, c'est désormais à moi de répondre.

Confiant, et à l'arrêt

Il y a une partie de cette période à laquelle je ne m'attendais pas. Plus je progressais, plus je me sentais confiant. Et en même temps, plus je me sentais à l'arrêt. Je savais livrer. Je connaissais bien la stack, les systèmes, la production. Cette confiance aidait à prendre des décisions, mais elle était très mauvaise pour me montrer où j'avais arrêté de progresser.

Ce qui m'a remis en mouvement, ce n'est pas une nouvelle technologie. Ce sont des personnes. J'ai commencé à recevoir davantage d'aide de développeurs plus expérimentés : des staff engineers, des managers, des seniors, des gens qui avaient autant d'années d'expérience que j'ai d'années tout court. Ça m'a énormément appris, et presque rien de tout ça ne concernait la syntaxe. Une bonne partie de ce que j'ai décrit plus haut, les questions que je me pose avant d'écrire quoi que ce soit, je l'ai appris en les regardant travailler.

L'autre sens m'a surpris davantage. Aider des personnes tout au début de leur carrière m'a aidé moi aussi. Expliquer quelque chose est le moyen le plus rapide de savoir si on le comprend vraiment, et répondre aux questions de quelqu'un d'autre oblige à organiser ce qu'on sait. Ça a façonné ma manière d'étudier, d'appliquer ce que j'apprends et de transmettre.

Je crois que c'est la partie de la séniorité qui ne tient pas sur un CV : apprendre de ceux qui sont devant soi tout en aidant ceux qui débutent, en même temps.

Le problème change

S'il fallait résumer tout ce changement en une phrase, ce serait celle-ci : le code reste difficile, mais il cesse d'être le goulot d'étranglement.

Ce qui devient difficile à la place :

Comprendre ce qu'il faut vraiment construire. Les besoins arrivent incomplets, et la partie manquante est généralement la partie importante.
Choisir des trade-offs. Chaque option coûte quelque chose. Le travail consiste à savoir quoi, et à le dire à voix haute.
Travailler dans des systèmes existants. L'essentiel du vrai travail n'est pas du greenfield. C'est modifier quelque chose dont les gens dépendent pendant qu'ils s'en servent.
Anticiper les conséquences. Le schéma choisi aujourd'hui décide de ce qui sera simple et de ce qui sera douloureux pendant les deux prochaines années.
Travailler dans l'incertitude. Décider avec 60 % de l'information parce qu'attendre les 100 % coûte plus cher.
Équilibrer vitesse et qualité. Pas comme un slogan. Comme un choix concret, sur une feature précise, cette semaine.
Comprendre l'impact. Une erreur frontend dans le checkout n'est pas un bug d'UI. C'est du chiffre d'affaires perdu qu'aucun dashboard technique ne montre.

Rien de tout ça ne remplace le code. Ça se pose par-dessus. Il faut toujours écrire la requête, le composant, la migration. Mais l'heure la plus difficile de la semaine se passe rarement dans l'éditeur.

Le marché le remarque

Il m'a fallu du temps pour voir que le marché suivait le même changement, simplement avec du retard.

Au début, la façon dont on est évalué se lit presque entièrement sur un CV : quelles technologies on connaît, quels frameworks, quels projets on a construits, combien d'années d'expérience on a, si on sait implémenter une feature. C'est logique. À ce stade, ce sont vraiment les meilleurs signaux de la capacité à exécuter.

À mesure que le périmètre grandit, ces signaux ne suffisent plus. Ce qui commence à compter est plus difficile à lister :

l'ownership : est-ce que ce que vous touchez va jusqu'au bout, y compris après le déploiement
l'autonomie : de combien de direction vous avez besoin pour faire avancer un problème
la prise de décision, et la capacité à expliquer les décisions prises
l'architecture, non pas comme des schémas mais comme des conséquences
l'impact sur le produit, pas seulement le volume livré
la communication, surtout sur les trade-offs et le risque
l'aisance face à l'ambiguïté
la capacité à relier un choix technique à ce que l'entreprise cherche à accomplir

Ce qui change, ce n'est pas seulement la façon dont on est évalué. C'est le type d'opportunité qui se présente. Les tâches cadrées deviennent des problèmes ouverts. « Tu peux construire ça ? » devient « tu peux trouver ce qu'on devrait faire ici ? ». La confiance est différente, et la responsabilité qui l'accompagne aussi.

Je veux être prudent ici. Ce n'est pas une promesse de salaire ni un parcours de carrière garanti. Les marchés diffèrent, les entreprises diffèrent, et beaucoup de gens sont sous-estimés ou surestimés pour des raisons qui n'ont rien à voir avec tout ça. C'est seulement ce que j'ai remarqué : la valeur perçue a tendance à suivre la taille des problèmes qu'on vous confie, plus que la longueur de votre liste de technologies.

Ce qui a changé pour moi

Si vous comparez ma stack de 2022 avec celle d'aujourd'hui, elle a grandi. Mais ce n'est pas ça qui a changé. Je pourrais lister toutes les technologies que j'ai utilisées, ça n'expliquerait pas la différence entre ma façon de travailler à l'époque et celle d'aujourd'hui.

Ce qui a changé, c'est par où je commence. Avant, je commençais par l'implémentation. Maintenant, je commence par le problème, et j'essaie de m'en méfier avant de lui faire confiance. Je demande ce qui se passe après le déploiement, qui s'en aperçoit quand ça casse, et à quoi on renonce. J'ai arrêté de considérer « personne n'a objecté » comme « c'était juste ».

J'ai aussi changé ce que je considère comme fini. Fini voulait dire mergé. Puis déployé. Aujourd'hui, ça veut dire que le problème est réellement résolu, et que je peux expliquer pourquoi cette solution et pas une autre.

Et presque rien de tout ça, je ne l'ai découvert seul. Ça vient de gens qui étaient passés par là avant moi, et d'avoir dû l'expliquer à ceux qui n'y étaient pas encore passés.

J'apprends encore

Je ne pense pas être arrivé quelque part. Il y a des choses sur lesquelles je travaille encore : savoir quand « assez bien » est vraiment assez, faire la différence entre un trade-off et un raccourci, et dire « je me suis trompé » plus vite qu'avant. Et j'apprends toujours de la même façon que j'ai appris presque tout : auprès de ceux qui sont plus loin, et en l'expliquant à ceux qui débutent.

Et je suis à peu près sûr qu'une partie de ce que je crois aujourd'hui me paraîtra naïve dans quelques années, comme mes premières décisions d'architecture me le paraissent maintenant. C'est normal. Je crois que c'est tout l'intérêt.

Le code restera une partie du métier. J'aime toujours en écrire, et je me méfie des ingénieurs qui cessent de s'en soucier. Mais à un moment donné, écrire du code cesse d'être la partie difficile. La partie difficile, c'est tout ce qui l'entoure : comprendre le problème, choisir à quoi renoncer, et assumer le résultat.

C'est la partie que j'apprends encore.