Il n'existe aucun moyen fiable d'attribuer un pourcentage à un travail d'ingénierie qui n'a jamais été mesuré, et inventer un chiffre pour satisfaire le conseil générique « chiffrez votre impact » est pire que de laisser le chiffre de côté, car une statistique inventée est soit fausse, soit impossible à défendre si quelqu'un vous demande d'où elle vient. Ce qui peut se décrire honnêtement, même sans indicateur suivi, c'est l'ampleur : la taille du système, le nombre de personnes ou de services qui en dépendaient, la fréquence à laquelle il tournait, et ce qui a réellement changé entre un état avant et un état après. Ce sont des faits que vous pouvez généralement reconstituer de mémoire, à partir d'un historique de tickets ou d'un rapport d'incident, et ils paraissent bien plus crédibles à un lecteur qu'un chiffre surgi de nulle part.
Pourquoi le conseil « ajoutez juste un chiffre » ne tient pas sans indicateur
La plupart des conseils de CV disent aux ingénieurs de chiffrer chaque ligne, et le conseil n'a rien d'absurde en soi : un lecteur qui parcourt des dizaines de CV réagit réellement mieux à quelque chose de concret qu'à une affirmation vague. Le problème, c'est qu'une grande partie du travail d'ingénierie réel n'a jamais été suivie d'une manière qui produise un pourcentage net. Beaucoup d'équipes ne tiennent pas de tableau de bord pour chaque changement, beaucoup d'impact se ressent plus qu'il ne se mesure, et beaucoup d'ingénieurs changent de poste avant que quiconque ne revienne vérifier si le changement du trimestre précédent a réellement aidé. Face à ce vide, le raccourci tentant est d'écrire un chiffre qui semble à peu près juste et d'espérer que personne ne demande d'où il vient. C'est exactement ce piège que cet article vise à vous aider à éviter, car un chiffre qu'un recruteur peut démonter d'une seule question fait plus de dégâts que l'absence de chiffre.
Des mesures honnêtes qui existent même sans indicateur suivi
Plusieurs types de détails concrets existent pour presque n'importe quel travail d'ingénierie, qu'un indicateur ait été enregistré ou non. L'ampleur décrit la taille de ce que vous avez touché : le nombre de services concernés par un changement, la taille de la base de code, le nombre de points d'entrée ou de tables affectés. L'échelle décrit ce que le système portait : le nombre de requêtes servies, le nombre d'enregistrements stockés, le nombre d'équipes qui s'appuyaient dessus, formulé dans des termes que vous pouvez énoncer avec assurance plutôt qu'un chiffre que vous devinez. La fréquence décrit la régularité d'utilisation ou d'exécution : une tâche par lots exécutée chaque nuit, un pipeline de déploiement utilisé par tous les ingénieurs de l'équipe, un rapport généré à chaque trimestre clos. L'état avant et après décrit ce qui était vrai avant votre changement et ce qui l'est devenu après, en langage clair plutôt qu'en pourcentage : ce qui échouait, ce qui nécessitait une étape manuelle, ce qui nécessitait une personne d'astreinte, et ce qui n'était plus vrai une fois le travail déployé. Qui en dépendait nomme le public réel : l'équipe qui utilisait l'outil que vous avez construit, le service qui appelait l'API que vous mainteniez, l'astreinte qui n'était plus sollicitée pour le problème que vous avez corrigé. Chacun de ces éléments est quelque chose que vous avez réellement vécu et pouvez décrire de première main, ce qui le rend justement bien plus défendable qu'un pourcentage arrondi.
Exemple illustratif : une ligne réécrite autour de l'ampleur plutôt que d'un pourcentage
Avant, vague et non chiffrée : « Responsable de la performance du service de paiement. » Après, réécrite autour de l'ampleur et d'un état avant/après décrit plutôt que d'un chiffre inventé : « Responsable de la couche de requêtes de base de données du service de paiement, le passage unique par lequel transitait chaque achat du site ; avant la réécriture, les requêtes lentes étaient la cause la plus fréquente d'un paiement bloqué que l'équipe support devait escalader, et après la mise en production, cette catégorie de plainte a cessé d'apparaître dans le tri hebdomadaire. » Rien dans la version réécrite n'est une statistique devinée. Elle indique ce dont la personne était responsable, à quel point cette partie était centrale pour le système, à quoi ressemblait le problème avant, et ce qui a changé après, le tout tiré de ce que la personne a réellement observé plutôt que d'un chiffre reconstitué a posteriori.
Ce qu'il faut laisser de côté dans la réécriture
La limite à tenir se situe entre un chiffre que vous pouvez citer aujourd'hui, issu d'un tableau de bord, d'un rapport d'incident ou d'un indicateur réellement suivi à l'époque, et un chiffre que vous reconstituez à partir d'un souvenir vague du type « on avait l'impression que tout allait beaucoup plus vite ». Le premier peut être cité directement sans problème. Le second est précisément celui qu'il vaut mieux réécrire avec un langage d'ampleur et d'avant/après à la place, car une impression mémorisée puis arrondie en un chiffre qui sonne bien est exactement le genre d'affirmation qui s'effondre face à une seule question précise en entretien. La version ci-dessus, fondée sur l'ampleur, résiste à cette question, car chaque élément est quelque chose que vous pouvez décrire avec vos propres mots sans vous appuyer sur un chiffre que vous n'avez jamais réellement enregistré.
Comment cela s'articule avec le schéma plus large des missions transformées en réalisations
Réécrire autour de l'ampleur plutôt que d'une statistique inventée est une application précise d'un changement plus large, qui s'applique bien au-delà de l'ingénierie : transformer une description de ce dont vous étiez responsable en une description de ce qui a réellement changé grâce à cela. Transformer des missions en réalisations sur un CV traite de ce schéma de réécriture plus large avec des exemples issus de métiers hors ingénierie, pour quiconque a des lignes qui se lisent aujourd'hui comme une liste de tâches assignées plutôt que de résultats.
Rédiger cette ligne
Comment rédiger un CV traite des choix de formulation qui portent ce type de réécriture sur le reste du CV, et le modèle developer de CVBuilderKit est justement conçu pour ce genre d'entrée centrée sur l'ampleur et le projet. Partez d'un document existant ou vierge dans l'éditeur et réécrivez chaque ligne en utilisant l'ampleur et un état avant/après décrit avant de vous tourner vers un chiffre que vous ne pouvez pas réellement défendre.