Ce n'est pas un bug, c'est une fonctionnalité — sens, origine et différences

Ce que signifie « Ce n'est pas un bug, c'est une fonctionnalité »

« Ce n'est pas un bug, c'est une fonctionnalité » — une phrase utilisée par un développeur ou un manager pour indiquer qu'un comportement inattendu du programme est intentionnel, pas erroné. Dans le cas classique, c'est une blague : tout le monde comprend que le comportement est erroné, mais on l'appelle « fonctionnalité » pour détendre l'atmosphère. Cependant, dans les projets réels, la phrase est aussi utilisée sérieusement — lorsque le comportement correspond effectivement à la spécification mais ne répond pas aux attentes de l'utilisateur.

La différence entre un bug et une fonctionnalité est souvent subjective. Pour un développeur qui a écrit le code, un certain comportement peut sembler logique. Pour un utilisateur, il peut sembler inattendu et erroné. La subjectivité de la perception est la principale raison pour laquelle la phrase est si persistante. Elle déplace la conversation de « qui est responsable » à « c'était conçu ainsi ». Selon UX Collective, 40 % des bugs signalés par les utilisateurs sont en réalité des problèmes d'UX, pas des erreurs de code.

Dans les équipes agiles, la phrase est souvent utilisée comme mécanisme de défense lors des démos. Le développeur montre un comportement inattendu, le product owner fronce les sourcils, et la phrase fatidique « ce n'est pas un bug, c'est une fonctionnalité » est prononcée. La confiance dans l'équipe détermine si la phrase sera prise comme une blague ou comme une tentative de cacher un problème. Dans une équipe saine, une telle blague détend l'atmosphère ; dans une équipe toxique, elle provoque un conflit.

Histoire de la phrase iconique

La première utilisation connue de la phrase a été enregistrée en 1976 dans un bulletin de la DECUS (Digital Equipment Corporation User Society). Un utilisateur se plaignait que le processeur de texte RUNOFF traitait incorrectement les lignes vides. La réponse du développeur : « Ce n'est pas un bug, c'est une fonctionnalité — c'est ainsi que les paragraphes sont traités. » Depuis lors, la phrase est devenue un symbole de défense du code écrit « tel quel », indépendamment de sa qualité réelle.

La popularisation de la phrase a été favorisée par le Jargon File — un dictionnaire d'argot hacker qui, dans les années 1990, a servi de base au livre « The New Hacker's Dictionary ». Dans le Jargon File, l'entrée « feature » fait directement référence aux bugs qui sont devenus des fonctionnalités parce qu'il était impossible ou non souhaitable de les corriger. Exemple : la touche Verr Maj sur les premiers terminaux n'avait pas de témoin lumineux — c'était un bug devenu une fonctionnalité « pour la frappe en aveugle ».

Dans les années 2000, la phrase est passée dans la culture populaire à travers les mèmes Internet. Une image de chat avec la légende « It's not a bug, it's a feature » s'est répandue sur les forums et les réseaux sociaux. Dans l'industrie du jeu vidéo, la phrase est utilisée particulièrement souvent : les glitches qui n'affectent pas le gameplay sont déclarés « fonctionnalités » pour l'ambiance. Le phénomène culturel s'est étendu bien au-delà de l'IT — la phrase peut être entendue dans tout contexte où une erreur est justifiée.

Psychologie de l'excuse : pourquoi on le dit

Le fondement psychologique de la phrase est la dissonance cognitive. Un développeur a passé des heures à écrire du code, et admettre que le résultat est erroné signifie dévaloriser son travail. La phrase « ce n'est pas un bug, c'est une fonctionnalité » réduit la dissonance : l'erreur se transforme en décision délibérée, et le développeur passe de coupable à auteur de l'idée. C'est un mécanisme de défense psychologique qui préserve l'estime de soi.

La deuxième raison est la peur du retravail. Admettre un bug signifie repasser par la revue de code, les tests et le déploiement. Une « fonctionnalité » ne nécessite pas de correction — la tâche est fermée, la charge de travail diminue. Selon Microsoft Research, les développeurs minimisent délibérément la gravité des bugs pour éviter le retravail dans 23 % des cas. La phrase est une forme légère de cette minimisation.

La troisième raison est la culture d'entreprise. Dans certaines entreprises, les bugs affectent les KPI du développeur, et trouver un bug lors de la revue de code est considéré comme une erreur de l'auteur. Dans un tel environnement, la phrase « ce n'est pas un bug, c'est une fonctionnalité » est un moyen d'éviter des conséquences négatives pour la carrière. Une culture de l'erreur saine (culture sans blâme) élimine cette raison : si les bugs ne sont pas punis, il est plus facile de les admettre.

Où se situe la frontière entre un bug et une fonctionnalité

Une frontière claire n'existe qu'en présence de Critères d'Acceptation. Si le comportement ne correspond à aucun élément des CA — c'est un bug. Si le comportement correspond aux CA mais que l'utilisateur ne l'aime pas — c'est un problème d'UX, pas un bug. S'il n'y a pas de CA — tout comportement peut être déclaré fonctionnalité, et c'est la principale raison de la persistance de la phrase.

Une règle pratique : un bug est quand un programme fait ce qu'il ne devrait pas, ou ne fait pas ce qu'il devrait, selon la spécification. Une fonctionnalité est quand un programme fait ce qui était prévu, même si le résultat surprend l'utilisateur. Cas limites : comportement indéfini (le langage ne définit pas le résultat), conditions de course (se manifestent de façon intermittente), cas extrêmes (fonctionne pour 99 % des données).

Pour clarifier, utilisez une matrice de décision :

• Le comportement est décrit dans la spécification et implémenté correctement — fonctionnalité, même si vous ne l'aimez pas
• Le comportement est décrit mais implémenté incorrectement — bug, nécessite une correction
• Le comportement n'est pas décrit mais découle logiquement des exigences — fonctionnalité non documentée, doit être ajoutée à la spécification
• Le comportement n'est pas décrit et est illogique — bug, les exigences doivent être clarifiées

Le cas le plus dangereux est lorsqu'il n'y a pas de spécification et que le développeur décide lui-même de ce qui est une fonctionnalité. Dans de tels projets, toute erreur peut être déclarée « fonctionnalité », rendant le code imprévisible pour toute l'équipe. Des Critères d'Acceptation clairs pour chaque tâche — la seule façon de tracer la frontière objectivement.

Pourquoi la substitution de concepts est dangereuse dans une équipe

Le premier danger est l'érosion de la qualité. Si chaque bug peut être déclaré fonctionnalité, l'équipe n'a aucune incitation à écrire du code de qualité. Les erreurs cessent d'être corrigées, la dette technique augmente, et les utilisateurs s'habituent au « comportement étrange ». Tôt ou tard, un concurrent lance un produit qui fonctionne de manière prévisible, et les utilisateurs partent.

Le deuxième danger est le conflit dans l'équipe. Un ingénieur QA trouve un bug, un développeur dit « c'est une fonctionnalité ». Sans critères objectifs (Critères d'Acceptation), la discussion devient personnelle : « tu testes mal » vs « tu programmes mal ». Selon PractiTest State of Testing 2023, les litiges « bug vs fonctionnalité » sont l'une des trois principales causes de friction entre QA et développeurs.

Le troisième danger sont les risques juridiques. Dans les industries réglementées (médecine, finance, aviation), les concepts de « bug » et de « fonctionnalité » ont un poids juridique. Si dans un logiciel médical un comportement est déclaré fonctionnalité mais conduit à un calcul de dosage incorrect — ce n'est pas une blague, c'est une violation des exigences réglementaires. Les systèmes critiques pour la sécurité ne tolèrent pas la substitution de concepts, c'est pourquoi ils utilisent toujours la vérification formelle.

Comment éviter la confusion entre un bug et une fonctionnalité

L'outil principal — des Critères d'Acceptation clairs dans chaque tâche. Les CA sont écrits avant le début du développement : « Lors de la saisie de X, le système doit produire Y ». Si le comportement n'est pas décrit — c'est un bug par défaut, même si le développeur pense le contraire. Les CA doivent être mesurables et vérifiables : « le bouton est vert » est mauvais, « HEX #00FF00 » est bon.

Le deuxième outil — une Définition de Fini dans l'équipe. Une description claire de ce que signifie « tâche terminée » : code écrit, tests écrits, tests passés, revue de code terminée, déployé en staging, testé par QA. Si tous les points de la Définition de Fini sont remplis et que l'utilisateur se plaint encore — ce n'est pas un bug, mais une exigence manquante qui va dans le backlog comme une nouvelle fonctionnalité.

Le troisième outil — une culture de post-mortem sans blâme. Si un bug a été déclaré fonctionnalité et est parti en production — nous analysons les causes, ne cherchons pas de coupable. Pourquoi le développeur a-t-il pensé que c'était une fonctionnalité ? Pourquoi le QA l'a-t-il manqué ? Pourquoi les CA étaient-ils incomplets ? Les réponses à ces questions améliorent le processus, ne punissent pas les personnes. Les améliorations systémiques fonctionnent plus efficacement que l'interdiction de la phrase « ce n'est pas un bug, c'est une fonctionnalité ».