Ce qu'un CTO attend vraiment d'un bon développeur

Le nombre de lignes écrites par un développeur n'a jamais figuré dans un tableau de bord utile. Ce qui compte, du point de vue de la direction technique, c'est le coût total d'une contribution sur cinq ans : combien de temps les autres passeront à la comprendre, à la corriger, à la faire évoluer et à la sécuriser.

Un bon développeur, dans cette définition, est celui qui réduit ce coût pour tout le monde. Voici ce que cela recouvre concrètement.

1. Écrire du code que quelqu'un d'autre reprendra sans vous

La maintenabilité n'est pas une affaire de style. Elle se mesure à une question simple : combien de temps faut-il à un développeur qui n'a pas écrit ce code pour y faire une modification en toute sécurité ?

Les pratiques qui font la différence sont peu nombreuses et très constantes : des noms explicites plutôt que des abréviations, des fonctions courtes avec une seule responsabilité, l'absence de logique cachée dans les effets de bord, et surtout la suppression du code mort. Un dépôt qui contient du code désactivé « au cas où » impose à chaque nouvel arrivant de deviner ce qui est vivant.

Une règle utile : si expliquer votre code à un collègue prend plus de cinq minutes, ce n'est pas le collègue qui a un problème.

2. Tester ce qui casse, pas tout

La couverture de tests n'est pas un objectif en soi. Un projet à 90 % de couverture peut être plus fragile qu'un projet à 45 % si les tests portent sur les mauvaises choses.

Ce qu'une direction technique attend :

• Des tests sur la logique métier : calculs, règles, cas limites, montants, droits d'accès.
• Des tests sur les parcours critiques : inscription, paiement, export de données.
• Un test de non-régression systématique après chaque incident en production. Un bug corrigé sans test reviendra.
• Peu de tests sur l'interface, coûteux à maintenir et vite obsolètes, sauf sur les deux ou trois parcours qui font vivre l'entreprise.

Un développeur qui écrit trois tests pertinents plutôt que trente tests décoratifs fait gagner de l'argent à l'entreprise.

3. Documenter les décisions, pas le code

La documentation qui compte n'explique pas ce que fait le code — le code le fait déjà. Elle explique pourquoi il est ainsi.

Trois formats suffisent : un fichier de démarrage qui permet à un nouvel arrivant de faire tourner le projet en moins d'une heure, une note d'une page par décision structurante (contexte, options écartées, choix, conséquences), et un commentaire ciblé partout où le code fait quelque chose de contre-intuitif pour une bonne raison.

Le test de qualité est simple : si vous partez trois semaines en congés, l'équipe peut-elle avancer sans vous appeler ?

4. Anticiper au lieu de subir

C'est le point qui distingue le plus nettement un développeur confirmé. Anticiper, c'est :

• Signaler qu'une fonctionnalité demandée entrera en conflit avec une autre dans deux mois.
• Prévoir le comportement du système quand un service externe est indisponible.
• Poser la question du volume de données à deux ans avant de choisir une structure.
• Alerter tôt sur un retard, avec une proposition d'ajustement du périmètre — pas la veille de la démonstration.
• Penser à la sécurité au moment de la conception : qui peut accéder à quoi, que se passe-t-il si cette entrée est malveillante.

Une alerte anticipée vaut souvent plus qu'une semaine de développement.

5. Communiquer comme si les autres avaient autre chose à faire

Un bon message de commit décrit l'intention, pas la manipulation. Une bonne pull request tient dans une taille lisible et explique ce qu'il faut vérifier. Un bon point d'avancement dit où l'on en est, ce qui bloque et ce dont on a besoin — en trois phrases.

Ces habitudes semblent secondaires. Elles déterminent en réalité la vitesse de toute l'équipe, parce qu'elles réduisent le nombre de sollicitations nécessaires pour comprendre l'état du travail.

Ce qui n'est pas attendu

Pour être juste, il faut aussi dire ce qu'une direction technique ne demande pas : connaître par cœur le dernier framework à la mode, travailler tard, répondre le week-end, ou avoir un avis sur tout. Un développeur reposé, qui dit clairement « je ne sais pas, je vais chercher », est infiniment plus précieux qu'un profil brillant et imprévisible.

Installer ces standards dans une équipe

Ces attentes n'ont de valeur que si elles sont explicites et outillées. Trois leviers, dans l'ordre :

1. Écrire les standards en une page et les afficher dans le dépôt.
2. Les automatiser : formatage, analyse statique, exécution des tests et vérification des dépendances vulnérables à chaque intégration. Ce qui est vérifié par la machine n'a pas besoin d'être rappelé en réunion.
3. Les incarner en revue de code, avec une règle : la revue commente le code, jamais la personne.

C'est la première chose que nous mettons en place dans notre accompagnement de direction technique : un cadre de qualité léger, outillé et compris de tous, plutôt qu'un règlement que personne ne lit.

FAQ

Comment évaluer un développeur autrement que par sa production ?

Regardez trois signaux : la fréquence des retours en arrière sur ses livraisons, le temps que les autres passent à comprendre son code en revue, et sa capacité à rendre les autres plus autonomes. Un développeur dont personne ne dépend et dont les modules ne cassent pas est bien plus rentable qu'un développeur rapide qui laisse une traînée de correctifs.

Faut-il exiger 100 % de couverture de tests ?

Non. Au-delà de 70 à 80 % sur la logique métier, le coût marginal dépasse largement le bénéfice, et l'objectif chiffré pousse à écrire des tests sans valeur pour satisfaire un seuil. Mieux vaut viser une couverture forte sur les parcours critiques et une politique stricte de test de non-régression après incident.

Un développeur junior peut-il tenir ces standards ?

Oui, souvent mieux qu'un profil expérimenté aux habitudes installées, à condition que les standards soient écrits, outillés et accompagnés en revue. La séniorité se mesure à l'autonomie face à l'ambiguïté, pas à la capacité à respecter des conventions — cela s'apprend en quelques semaines.