Vous avez livré le sprint, géré l'incident, tenu votre bilan devant des collègues américains. Puis ce silence poli — celui qui signifie, sans le dire, que vos formulations trahissent un développeur qui n'a pas encore le registre attendu dans leurs équipes.
Tester Amélie gratuitementCes 25 termes couvrent l'intégralité du cycle de bilan : de la phase de livraison à la revue post-incident, en passant par la gestion des priorités et la communication vers les parties prenantes.
1. To ship (shipped) — Livrer une fonctionnalité en production avec sa valeur business. "We shipped the auth refactor last Thursday." Ne jamais substituer "finished" ou "completed" dans ce sens.
2. Scope creep — Dérive non contrôlée du périmètre en cours de sprint. "The timeline slipped due to scope creep in week three."
3. Rollback — Retour arrière sur un déploiement défaillant. "We triggered a rollback at 03:12 after the latency spike."
4. Root cause — Cause racine identifiée après analyse. Toujours dans "root cause analysis" (RCA). "Root cause was a missing index on the payments table."
5. Bottleneck — Goulot d'étranglement dans un flux système ou humain. "The bottleneck was the third-party KYC API, not our service."
6. Technical debt — Dette technique accumulée. "We're carrying significant technical debt in the legacy auth module."
7. Workaround — Solution de contournement temporaire, explicitement non définitive. "We shipped a workaround while the permanent fix goes through review."
8. Throughput — Débit traité par unité de temps. "Our throughput dropped 40% during the incident window."
9. Latency — Temps de réponse d'un système. "P99 latency spiked to 4 seconds. SLA target is 500ms."
10. To flag (an issue) — Signaler formellement un risque ou problème. "I flagged this dependency risk two sprints ago."
11. Ownership — Responsabilité nommée et assumée sur un composant ou une décision. "There was no clear ownership on the migration script."
12. Blocker — Obstacle bloquant l'avancement d'un ticket ou d'une équipe. "The main blocker was waiting on legal sign-off for the data schema."
13. Deliverable — Livrable formel engagé auprès des parties prenantes. "The three deliverables for Q2 were: new onboarding API, SSO integration, audit logs."
14. To iterate — Affiner progressivement sur la base de mesures. "We're iterating on the caching strategy based on last week's metrics."
15. Edge case — Cas limite hors du chemin nominal. "The bug was an edge case triggered only with ISO 8601 dates before 1970."
16. To deprecate — Marquer comme obsolète avec calendrier de migration. "We deprecated the v1 endpoint. Clients have 90 days to migrate."
17. SLA (Service Level Agreement) — Engagement de niveau de service contractualisé ou interne. "We breached SLA twice this quarter. Both incidents are documented."
18. To triage — Qualifier et prioriser des incidents ou tickets entrants. "We triaged 12 new issues this week; three are P0."
19. Post-mortem — Bilan formalisé après un incident en production. "The post-mortem is scheduled for Monday. Draft is in Confluence."
20. On-call — Astreinte de permanence technique. "I was on-call during the incident. My response time was under eight minutes."
21. Stakeholder — Partie prenante ayant un intérêt dans le livrable. "Stakeholders were notified within 15 minutes of the incident declaration."
22. Bandwidth — Capacité humaine disponible, pas seulement réseau. "We don't have the bandwidth to take on the migration this sprint."
23. Retrospective — Cérémonie agile de bilan d'équipe (distinct du post-mortem d'incident). "Three action items came out of the retro: improve monitoring, reduce WIP, clarify PR ownership."
24. To surface (an issue) — Remonter un problème à la visibilité de l'équipe ou du management. "This risk was surfaced early but deprioritized."
25. Trade-off — Compromis explicite et assumé entre deux options contradictoires. "The trade-off was speed vs. test coverage. We chose speed; here's what we'll pay back."
Un calque est une traduction mot à mot d'une structure française qui produit une phrase grammaticalement correcte mais professionnellement anormale en anglais. En contexte de bilan de projet, ils signalent immédiatement un locuteur qui pense en français. En voici les plus fréquents chez les développeurs.
"We realized the feature" — calque direct de "réaliser une fonctionnalité". En anglais, realize signifie prendre conscience. Le natif entend : l'équipe vient de comprendre que la fonctionnalité existait. Formulation attendue : "We implemented / built / shipped the feature."
"We have followed the planning" — calque de "suivre le planning". Cette construction n'existe pas en anglais professionnel. On dit : "We stayed on track", "We met the timeline", "We hit the deadline". La formulation française signale une pensée directement traduite.
"There was a problem of performance" — double erreur : calque de "problème de" et absence de précision quantitative. Un ingénieur crédible dit : "We hit a performance regression — P95 latency went from 180ms to 2.1 seconds."
"I worked on this ticket" — techniquement compréhensible, mais vague au point d'être inutile en bilan. Formulation attendue selon l'état : "I owned this ticket", "I closed this ticket", "I shipped a fix for this ticket."
"We make a debrief" — le verbe idiomatique est run ou hold : "We ran a post-mortem", "We held a retrospective". La structure "make/do a debrief" n'existe pas dans ce registre.
"We didn't have the time" — perçu comme une excuse passive dans une culture qui valorise l'ownership des décisions. Formulation attendue : "We deprioritized X to protect Y. That was a deliberate trade-off."
En bilan de projet, la structure compte autant que le vocabulaire. Les équipes anglo-saxonnes attendent un enchaînement précis : résultat factuel, cause identifiée, action corrective nommée. Voici dix formulations qui respectent ce cadre.
1. "We shipped [X] on time / two days late. Root cause of the delay was [Y]." — Résultat + cause directe, sans passif.
2. "The incident lasted 47 minutes. We triggered a rollback at T+12. Full RCA is linked in the doc." — Précision temporelle systématique.
3. "We deprioritized [feature] to protect the [deadline]. That was a deliberate trade-off." — Ownership de la décision, pas justification.
4. "Three action items came out of the retro. [Name] owns each one. Due date: end of next sprint." — Attribution nominale, jamais de passif sans responsable.
5. "Technical debt in [module] is now blocking [feature]. We need to schedule a refactor sprint." — Lien causal explicite entre dette et impact business.
6. "Stakeholders were notified at T+15. Status page updated at T+20." — Timeline de communication, standard incident management.
7. "We're going into next sprint with three open P1s. Here's the triage." — Quantification + état précis, pas d'approximation.
8. "The workaround is live. Permanent fix is scoped and in the backlog — estimated two sprints." — Distinction explicite entre mesure temporaire et solution définitive.
9. "We breached SLA once this quarter. MTTR was 52 minutes against our 30-minute target." — Métriques nommées, comparaison à la cible.
10. "This edge case wasn't covered by our test suite. We're adding coverage before we close the incident." — Responsabilité technique assumée sans posture défensive.
La prononciation de termes techniques courants est une source d'érosion de crédibilité silencieuse. Ces erreurs ne sont jamais corrigées en réunion — elles sont simplement enregistrées.
Workaround : /ˈwɜːrkəˌraʊnd/. Le "work" se prononce avec le son /ɜː/ (comme "word"), pas /ɔ/ à la française. Erreur fréquente : accentuation sur "ka" au lieu de la première syllabe.
Deprecate : /ˈdeprikeɪt/. Accent sur la première syllabe, terminaison en /keɪt/. Les francophones tendent à dire de-PRE-cate par analogie avec le français.
Throughput : /ˈθruːpʊt/. Le "th" est fricatif /θ/ (comme dans "think"), pas /t/. Dire tru-put est perçu comme une erreur phonétique élémentaire.
Latency : /ˈleɪtənsi/. La première syllabe est longue : /leɪ/, non /lat/. La-ten-cy à la française signale immédiatement un locuteur non natif dans un contexte de performance système.
Stakeholder : /ˈsteɪkhoʊldər/. "Stake" se prononce /steɪk/, non stak. Fréquemment misprononcé par analogie phonétique avec "stack" (terme réseau).
Retrospective : /ˌretrəˈspektɪv/. Accent sur la troisième syllabe. Les francophones accentuent souvent la première : RE-tro-spec-tive.
Triage : /triˈɑːʒ/ en anglais américain, /ˈtriːɑːʒ/ en anglais britannique. Mot d'origine française dont la prononciation anglaise diverge légèrement du français standard — l'accent tonique se déplace. Prononcer le mot à la française dans une équipe anglophone produit un léger décalage perçu.
À éviter : We realized the new authentication feature last sprint.
Comment le natif l'entend : We became aware the authentication feature existed. The team sounds confused about what they built.
Préférer : We shipped / implemented / delivered the new authentication feature last sprint.
En anglais, 'realize' signifie prendre conscience de quelque chose — jamais construire ou produire. C'est l'un des faux amis les plus coûteux en contexte de bilan, parce que l'erreur est invisible pour le locuteur mais immédiatement perçue par le natif. En réunion de bilan, l'effet est désastreux : le manager entend une équipe incertaine de ce qu'elle a livré.
À éviter : We have followed the planning and delivered on time.
Comment le natif l'entend : Oddly phrased. 'Follow the planning' doesn't exist in this register. Either translating from French or not comfortable with professional English.
Préférer : We stayed on track and hit the deadline. / We delivered on schedule.
'Follow the planning' est une traduction mot à mot de 'suivre le planning' — construction inexistante en anglais professionnel tech. Les natifs disent 'stay on track', 'hit the deadline', 'meet the timeline', 'deliver on schedule'. Chaque formulation française traduite littéralement accumule du capital négatif sans que l'interlocuteur intervienne.
À éviter : We had a problem of performance during the deployment.
Comment le natif l'entend : Junior register. 'Problem of performance' does not exist. No metrics, no precision. This person is not fluent in incident language.
Préférer : We hit a performance regression during the deployment — P95 latency spiked from 180ms to 2.1 seconds.
La construction 'problem of [X]' calque directement 'problème de'. En anglais tech, on dit 'performance issue', 'performance regression', ou mieux : on quantifie immédiatement. L'absence de métriques dans un bilan de performance est perçue comme un manque de rigueur technique, pas seulement comme une erreur de registre.
À éviter : We did a debrief after the incident and found some issues.
Comment le natif l'entend : Informal and imprecise. 'Some issues' without quantification or ownership signals immature incident management culture.
Préférer : We ran a post-mortem after the incident. Three action items were identified, each with a named owner and a due date.
En anglais professionnel, on ne 'fait' pas un debrief — on 'runs a retrospective', 'holds a post-mortem', 'conducts a review'. Le choix du verbe n'est pas stylistique : il signale une culture de gestion structurée. 'Some issues' sans quantification ni attribution est une non-réponse dans n'importe quelle culture d'ingénierie anglo-saxonne.
À éviter : I worked on this ticket for most of the sprint.
Comment le natif l'entend : What is the status exactly? Done? Blocked? Still in progress? This gives no actionable information for planning.
Préférer : I owned this ticket. Shipped a fix on Thursday. It's in staging, pending QA sign-off.
'Work on' est trop vague pour un bilan. En anglais pro tech, on nomme l'état réel : 'I owned', 'I closed', 'I shipped a fix for', 'I'm blocked on'. L'ownership language est une attente culturelle forte dans les équipes anglo-saxonnes — préciser ce qu'on a fait exactement est une marque de maturité, pas d'arrogance.
À éviter : We didn't have the time to finish the migration.
Comment le natif l'entend : Excuse-framing. Things happen to this team — they don't make decisions. Not reassuring in a senior engineer presenting to leadership.
Préférer : We deprioritized the migration to protect the API deadline. Deliberate trade-off. Migration is scoped for next sprint.
'We didn't have the time' est une formulation passive dans une culture qui valorise l'ownership des arbitrages. La formulation attendue nomme le trade-off : qu'a-t-on sacrifié, pourquoi, et quel est le plan de rattrapage. La différence entre excuser un manque et posséder une décision est entièrement dans le choix des mots.
À éviter : I updated the stakeholders about the incident.
Comment le natif l'entend : Understandable, but imprecise for incident context. When? What format? What was the content of the update?
Préférer : I notified stakeholders at T+15. Status page updated at T+20. Full incident summary sent at T+120.
'Update someone about' fonctionne mais reste flou. Dans un bilan d'incident, les natifs attendent des verbes précis : 'notify' pour la notification initiale, 'brief' pour le résumé oral, 'send a status update' pour l'écrit récurrent. La précision temporelle (T+15, T+20) est une convention de l'incident management anglo-saxon — son absence signale une culture immature de la communication de crise.
Un post-mortem est spécifiquement déclenché par un incident en production : panne, breach de SLA, perte de données. Son objectif est l'analyse causale et les actions correctives formalisées. Une rétrospective ("retro") est une cérémonie agile régulière qui porte sur le fonctionnement de l'équipe : process, communication, vélocité. Utiliser l'un pour l'autre dans un bilan technique signale une confusion sur la culture d'ingénierie attendue.
La formulation qui préserve la crédibilité nomme la cause et le plan : "We slipped by two days due to an unplanned dependency on the payments service. We've adjusted scope and are on track for Thursday." Évitez 'we are late' seul — sans cause ni plan, c'est une déclaration d'échec sans ownership. Le verbe technique standard pour un retard partiel est 'to slip' : "a two-day slip", "the timeline slipped".
'Deploy' et 'ship' ne sont pas synonymes en contexte de bilan. 'Deploy' est une action technique : pousser du code en production. 'Ship' est un acte produit : livrer une fonctionnalité avec sa valeur business. On peut déployer un hotfix sans shipper une feature. En bilan, 'we shipped X' communique que X est fonctionnel, disponible, et créateur de valeur — pas juste présent en production. Utiliser 'deploy' seul est correct mais sous-communique.
La structure attendue est : résultat factuel, cause identifiée, impact quantifié, action corrective nommée. "The feature didn't ship. Root cause: a misconfigured staging environment masked a critical bug. Impact: two-day slip. Fix: we've added a pre-deploy checklist, owned by [name]." Ce cadre est culturellement valorisé — il montre de la rigueur, pas de la faiblesse. Le hedging et les approximations sont bien plus dommageables qu'un échec honnêtement présenté.
Oui, c'est un usage courant et professionnel dans les équipes tech anglophones. "I don't have the bandwidth to take this on" signifie : je n'ai pas la capacité disponible. C'est idiomatique, pas argotique. Les francophones qui ne connaissent pas cet emploi disent souvent "I don't have the time" ou "I'm overloaded", ce qui fonctionne mais est moins précis dans un contexte de planification — et signale qu'on n'est pas natif du registre.
Non — c'est l'inverse. Dans les équipes tech mixtes, le vocabulaire technique anglais (post-mortem, rollback, SLA, triage) est la lingua franca précise, même entre francophones. Ce qui crée des problèmes, c'est le mélange de structures syntaxiques françaises avec des mots anglais — les calques. La règle pratique : utilisez le vocabulaire technique anglais standard, mais vérifiez que vos phrases complètes suivent une syntaxe anglaise, pas une syntaxe française traduite mot à mot.
Amélie écoute ton anglais oral, repère les calques du français invisibles à toi-même, et te corrige avec la version native pro. 90 secondes pour le diagnostic.
Lancer le diagnostic gratuit