Qu'est-ce qui distingue un bon codeur d'un bon ingénieur logiciel ?

Question

Accepted Answer

Un **bon codeur écrit du code qui fonctionne**. Un **bon ingénieur logiciel résout le bon problème de manière holistique** — en s'appropriant les exigences, la conception, les tradeoffs, la maintenabilité, les tests, les opérations, et le contexte métier autour du code. L'ingénierie, c'est le code plus le jugement plus la responsabilité sur tout le cycle de vie.

## Où se situe vraiment la ligne

Écrire du code qui passe les tests est la partie facile, apprenable. La partie plus difficile et plus valuable, c'est tout ce qui l'entoure : décider *quoi* construire, *comment* cela devrait s'intégrer au système, et *quel sera le coût* de vivre avec plus tard.

- **Un codeur demande** « Comment je fais fonctionner ça ? » et s'arrête quand ça marche.
- **Un ingénieur demande** « Quel problème résolvons-nous vraiment, quelles sont les contraintes, et quel est le design le moins coûteux qui survivra aux changements ? »

## Ce dont l'ingénieur est responsable au-delà du code

- **Exigences** — clarifie le vrai besoin, remet en question la spécification, met en lumière les cas limites avant qu'ils ne deviennent des incidents.
- **Tradeoffs** — pèse vitesse vs. simplicité, construire vs. acheter, maintenant vs. plus tard, et rend le choix *explicite*.
- **Conception et maintenabilité** — écrit pour le prochain lecteur, garde le rayon d'impact petit, évite la complexité accidentelle.
- **Tests et opérations** — pense aux modes de défaillance, à l'observabilité, au rollback, et à ce qui se passe à 3 heures du matin.
- **Communication** — explique les décisions, les met par écrit, et embarque les autres.
- **Contexte métier** — lie le travail aux résultats, pas seulement aux tickets fermés.

## Une nuance utile

Ce n'est **pas** une question d'ancienneté ou de titre — beaucoup « d'ingénieurs » codent, et certains « codeurs » font de l'ingénierie. C'est une **mentalité** : prendre la responsabilité du résultat, pas seulement du résultat du travail. Le décalage va de *« mon code fonctionne »* à *« ce système remplit son objectif, de manière fiable, et ne punira pas celui qui le touchera ensuite ».*

## Pourquoi c'est important

Les recruteurs et les équipes valorisent l'ingénieur plutôt que le codeur parce que **les bugs, les pannes et les systèmes non maintenables ne viennent rarement d'un code qui ne compile pas — ils viennent d'un manque de jugement** : la question non posée, le tradeoff ignoré, le cas limité non testé. Démontrer que vous pensez à tout le cycle de vie — et que vous pouvez articuler *pourquoi* vous avez choisi un chemin plutôt qu'un autre — c'est ce qui signale que vous pouvez être confié à de vrais systèmes et de vraies conséquences, ce qui est exactement ce que signifie progresser dans cette carrière.