Mon code ne marche pas, comment trouver et corriger un bug ?

Vous venez de passer trois heures à coder. Vous lancez votre programme. Et là…​ ça ne marche pas ! C’est un bug. Peut-être que :

• Un message d’erreur incompréhensible s’affiche
• Votre code ne fait pas ce qu’il devrait faire
• Pire, votre programme ne fait rien du tout

Vous avez modifié quelques lignes, vous relancez. Ça ne marche toujours pas. Vous essayez autre chose, puis encore une autre. Vous cherchez sur Internet. Vous copiez du code trouvé sur un forum, mais rien n’y fait. Vous êtes toujours bloqué au même endroit.
Vous êtes certainement frustré, et vous vous demandez comment trouver et corriger ce satané bug !

Dans cet article, vous allez découvrir :

• La réalité et les erreurs courantes faîtes par les développeurs juniors
• Comment trouver et corriger un bug efficacement comme les professionnels
• Ce qu’il vous manque réellement pour devenir autonome face aux bugs

Pourquoi votre code ne marche pas ?

Les bugs sont normaux, même chez les professionnels

Vous serez probablement soulagé d’apprendre que des bugs dans une application sont absolument normaux.

En effet, avec le temps et l’expérience, un développeur apprend à écrire du code plus robuste, à anticiper certains problèmes. Pour autant, il est rare qu’un programme fonctionne parfaitement du premier coup, même pour les experts.

La différence ? Les développeurs expérimentés savent comment identifier et corriger rapidement les erreurs quand elles surviennent. Ils ont une méthode pour diagnostiquer les problèmes, comprendre ce qui ne va pas, et appliquer une solution efficace.

Les différents types de bugs

Nous pouvons classer les bugs en trois grandes catégories :

• Les erreurs de syntaxe : ce sont des erreurs dans la structure du code qui empêchent le programme de compiler ou de s’exécuter. Par exemple, oublier une parenthèse ou une accolade, oublier un import, etc. Ces erreurs sont généralement détectées immédiatement par l’interpréteur ou le compilateur. Vous voyez un message d’erreur clair qui vous indique où se trouve le problème. Il est rare qu’un développeur, même débutant, reste bloqué longtemps sur ce type d’erreur.
• Les erreurs d’exécution : ce sont des erreurs qui surviennent pendant l’exécution du programme, souvent à cause de conditions imprévues ou d’une mauvaise utilisation d’une librairie. Par exemple, essayer de diviser par zéro, accéder à un index hors limites dans un tableau, ou manipuler une variable non initialisée. Ces erreurs lèvent souvent des exceptions, ce qui facilite grandement leur identification. Cependant, comprendre pourquoi elles se produisent peut être plus complexe.
• Les erreurs logiques : ce sont les bugs les plus sournois. Le programme s’exécute sans erreur, mais le résultat n’est pas celui attendu. Par exemple, une fonction de calcul d’un prix qui applique des réductions au mauvais moment, un décodage incorrect des données, etc. Ces erreurs sont difficiles à détecter car il n’y a pas de message d’erreur. L’algorithme exécute les instructions correctement, mais à une certaine étape, le traitement des données est effectué sur la base d’une mauvaise hypothèse. Le résultat est alors incorrect. Pour ce type de bug, il faut comprendre le comportement du programme et identifier où le traitement ne fait pas à ce qui était prévu.

J’ai justement présenté dans un précédent article un cas d’erreur de logique difficile à reproduire et une méthode pour la diagnostiquer et la corriger. N’hésitez pas à le lire pour découvrir un exemple concret.

L’erreur classique des débutants pour corriger un bug

Maintenant que vous y voyez plus clair sur les types de bugs, parlons de la façon dont les débutants tentent souvent de les corriger.

Je vais vous décrire trois approches typiques que j’ai vues chez les développeurs juniors. Si vous vous reconnaissez, ne vous inquiétez pas, c’est normal. Face à un bug, on adopte souvent des comportements intuitifs qui ne fonctionnent pas.

Modifier le code au hasard « pour voir si ça corrige le bug »

Quand vous concevez la logique d’un programme, vous avez souvent une idée de ce que le code devrait faire et une hypothèse sur la façon dont les différentes parties interagissent. Malheureusement, cette forte conviction vous aveugle face à la réalité et vous empêche de diagnostiquer correctement le problème.

Vous ne comprenez pas pourquoi, vous vous sentez perdu et vous commencez à modifier des choses au hasard dans l’espoir que ça finisse par marcher. Par exemple :

• Vous changez l’ordre de quelques lignes
• Vous ajoutez une condition supplémentaire
• Vous modifiez une valeur « pour voir »
• Vous commentez une partie du code
• Vous relancez le programme en espérant un résultat différent

Cette approche est équivalente à frapper un appareil quand il ne fonctionne pas. Parfois, par chance, ça peut débloquer la situation. Mais vous n’avez rien résolu, vous ne comprenez toujours pas ce qui s’est passé, et vous risquez de le retrouver plus tard.

Copier une solution trouvée sur Internet sans contexte

Une autre mauvaise solution est de chercher l’erreur sur Google ou demander une solution à ChatGPT. Par exemple, vous tomber sur un forum comme stack overflow où quelqu’un a apparemment le même problème, et vous copier-coller la solution proposée sans vraiment comprendre.

Parfois ça marche. Vous êtes soulagé, vous passez à autre chose. Mais le plus souvent ça ne marche pas…​

• Le contexte de l’autre personne est différent du vôtre,
• La solution proposée corrige un problème spécifique qui n’est pas exactement le vôtre,
• Ou vous n’avez pas compris ce que fait le code que vous avez copié.

Le danger derrière cette approche, c’est que vous devenez dépendant d’Internet ou d’autres sources externes. Vous restez donc incapable de diagnostiquer et résoudre les problèmes par vous-même.

Ajouter des traces sans plan précis

Ajouter des traces (des instructions d’affichage) pour « voir ce qui se passe » est déjà une meilleure approche que les deux précédentes. Cela dit, faut-il encore savoir quoi afficher et quand.

L’ajout d’instructions d’affichage est une technique classique pour comprendre la dynamique d’un programme. Cependant, elle demande du temps :

1. On parcourt le code pour ajouter des traces
2. On analyse les résultats obtenus pour espérer identifier le bug
3. On passe une seconde fois sur le code pour supprimer les instructions une fois le bug corrigé

Le problème ? Sans hypothèse claire sur ce que vous cherchez à observer, vous vous retrouverez à afficher et analyser une quantité énorme d’informations dont la plupart sont inutiles, ce qui ralentira votre diagnostic.

Pourquoi ces approches vous frustrent ?

Ces approches ont un point commun :

• Vous passer des heures à essayer différentes modifications sans résultat
• Vous avez l’impression de tourner en rond
• Vous perdez confiance en vos capacités

Au final, vous vous sentez frustré, découragé et démuni face à votre code.

C’est normal, sans une bonne méthode il est difficile de prendre du plaisir et de développer une compétence réutilisable pour diagnostiquer et corriger les bugs efficacement.

D’ailleurs, si vous voulez éviter d’autres erreurs classiques qui ralentissent votre progression, découvrez les 9 erreurs de programmation faites par les débutants et comment y remédier. Vous y découvrirez notamment pourquoi coder sans une bonne réflexion risque d’introduire plus de bugs dans votre code.

Pourquoi corriger un bug sans méthode ne fonctionne pas ?

Maintenant, comprenons pourquoi ces approches intuitives sont mauvaises et fonctionnent rarement.

Le code comme un bug n’est jamais « magique »

Quand votre code ne fonctionne pas, vous avez peut-être l’impression que l’ordinateur fait n’importe quoi. Qu’il y a quelque chose de magique ou d’inexplicable dans ce qui se passe.

En réalité, c’est faux. L’ordinateur exécute bêtement et à la lettre les instructions que vous lui avez données.

Si le résultat n’est pas celui que vous attendiez, c’est parce que vos instructions ne correspondent pas à ce que vous pensiez avoir écrit ou que vous n’avez pas anticipé certains effets de bord.

Le bug est toujours logique et explicable. Le problème, c’est qu’en tant que novice, il est difficile d’avoir une idée claire de ce qui se passe réellement dans le programme.

Sans méthode, on corrige le symptôme, jamais la cause du bug

Quand vous modifiez votre code au hasard et que ça finit par « marcher », vous ne savez pas vraiment ce que vous avez corrigé et pourquoi.

La plupart du temps, vous avez corrigé le symptôme du problème, pas la cause. De plus, vous ne maîtrisez plus vraiment votre code et vous ne comprenez toujours pas ce qui n’allait pas au départ.

C’est comme prendre de l’aspirine contre la fièvre. Elle finit par baisser, vous vous sentez mieux, mais l’infection qui a causé cette fièvre est toujours là et peut empirer.

En programmation, c’est exactement pareil. Si vous ne comprenez pas la cause réelle du bug, vous allez probablement corriger votre cas particulier en laissant le problème réel intact.
Par expérience, vous pouvez être quasi certain que ce bug réapparaîtra plus tard !

Le bug revient ailleurs, plus tard, plus grave

En informatique, on dit souvent « si ça marche, on n’y touche plus ».

Vous avez un bug, vous corrigez le symptôme en masquant le vrai problème. En l’état actuel, votre application « fonctionne ».

Le problème c’est qu’une application reste rarement en production sans évoluer. Certains besoins émergent ou changent, vos utilisateurs détournent certaines fonctionnalités, vous ajoutez de nouvelles fonctionnalités.

Résultat, la rustine artisanale que vous avez appliquée ne tient plus. L’application plante dans des endroits qui fonctionnaient avant. Vous ne comprenez pas ce qui se passe.

En masquant le problème, il ressurgit sous une autre forme et souvent plus difficile à diagnostiquer parce qu’il a introduit d’autres effets de bord.

Le coût caché de l’absence de méthode

Au-delà du temps perdu immédiatement, corriger sans méthode a un coût caché beaucoup plus important :

• Votre code devient de plus en plus fragile : chaque correction approximative ajoute de l’instabilité
• Vous perdez la maîtrise de votre programme : vous ne savez plus vraiment ce qui se passe dans votre code
• Vous développez une peur de modifier le code : toucher au code devient risqué parce que vous ne comprenez plus les implications

Le résultat ? Après quelques évolutions, votre projet devient un château de cartes. Vous n’osez plus y toucher de peur que tout s’écroule.

J’ai même vu certains projets repris de zéro parce que le code était mal conçu et complètement instable à cause de multiples correctifs appliqués au fil du temps.

Ce que font les développeurs expérimentés face à un bug

Alors, comment font les développeurs qui corrigent leurs bugs efficacement ? Quelle est leur approche ?

Comprendre ce que fait réellement le programme

Lorsqu’un bug survient, nous arrivons assez rapidement à isoler la zone du code où le problème se manifeste (un job, une action IHM, etc.).

La méthode consiste d’abord à chercher et à comprendre ce que fait réellement le programme dans ce code. Quelle est la séquence d’instructions exécutée ? Quelles données sont manipulées ? Quel devrait être l’état du programme à ce moment-là ?

Selon la taille du code, on peut s’arrêter à une compréhension globale du traitement afin de cibler la ou les zones susceptibles de provoquer le bug.

Tester une hypothèse à la fois

Il n’y a pas de hasard dans cette méthode.

La zone suspecte du code suggère une ou plusieurs hypothèses sur la cause possible du bug. Pour chaque hypothèse, nous allons effectuer un test isolé pour la valider ou l’invalider.

Cela passe par l’observation chirurgicale de la dynamique du programme :

• Si l’hypothèse est confirmée, nous savons où intervenir.
• Sinon, nous passons à l’hypothèse suivante.

C’est une approche scientifique qui garantit une progression systématique vers la solution, au lieu d’avancer aléatoirement.

Observer l’état interne du code au bon moment

On ne commence à observer la dynamique du programme qu’après avoir identifié une zone suspecte et formulé une hypothèse claire.

Cette phase d’observation consiste à mettre en place les moyens qui permettent de comprendre l’état interne de notre programme au moment précis où le bug se produit.
En effet, sans zone d’intervention ou d’hypothèse à vérifier, difficile de savoir quoi observer :

• Quelles variables doivent être inspectées ?
• Dois-t’on tracer le cheminement du traitement dans une condition ou une boucle ?
• Quels événements doivent être suivis ?

On ne récupère pas ces informations par hasard. Ce sont les hypothèses formulées qui nous permettent de choisir la bonne stratégie. Et pour la mettre en oeuvre, les professionnels utilisent deux outils principaux :

• Les journaux (logs en anglais) : des instructions qui affichent ou enregistrent les informations souhaitées au fur et à mesure de l’exécution.
• Le débogueur : un outil qui permet de mettre en pause l’exécution du programme à un point précis, d’inspecter l’état interne (valeurs des variables, pile d’appels, etc.), et de suivre l’exécution pas à pas.

Si vous vous demandez où vous pouvez trouver un débogueur, sachez que c’est dans un bon IDE (environnement de développement intégré). Un logiciel qui fait partie des 5 outils indispensables à tout développeur.

Corriger la cause du bug à sa source

Une fois que l’hypothèse correcte est identifiée, la correction consiste à modifier le code à l’endroit exact où le problème se situe.

Il ne s’agit pas seulement de traiter le cas particulier qui a déclenché le bug, mais de comprendre pourquoi le code ne fonctionne pas comme prévu et de corriger la logique sous-jacente.
Cela peut passer par une nouvelle conception de l’algorithme, une meilleure gestion des données, ou une modification de la structure du code.

A ce stade, l’objectif est de s’assurer que la correction résout le problème de manière durable pour garantir la stabilité du système.

Pourquoi vous ne faites pas ça spontanément ?

Si cette approche est si efficace, pourquoi ne la faites-vous pas naturellement ?

1. Sans méthode, vous vous retrouvez en panique et vous finissez par faire n’importe quoi.
2. Sans expérience, il est difficile d’identifier les zones de code suspectes et de formuler des hypothèses pertinentes.
3. Sans formation, vous ne connaissez ni les outils, ni les techniques pour observer l’état interne d’un programme.

Avec le temps, vous finiriez par développer une méthode empirique qui ressemble à celle-ci. Cependant, cela demande du temps et cette difficulté initiale décourage beaucoup de débutants qui finissent par abandonner la programmation. Heureusement, le débogage est une compétence qui s’apprend !

Ce qu’il vous manque vraiment pour corriger vos bugs efficacement

Résumons ce que nous avons vu jusqu’ici :

• Les bugs sont normaux, même chez les professionnels
• Modifier au hasard ne fonctionne pas et crée plus de problèmes qu’il n’en résout
• Les développeurs expérimentés utilisent une méthode précise basée sur l’observation et les hypothèses
• Le débogage est une compétence distincte de la programmation et qui s’apprend

Mais concrètement, qu’est-ce qui vous manque pour adopter cette approche efficace du débogage ?

Des qualités et un état d’esprit adaptés

Le parcours de chacun est différent. Certains ont eu l’opportunité de développer des qualités comme la patience, la rigueur, et l’esprit d’analyse avant de se lancer dans la programmation.

Comme je le présente dans l’article « Le codage d’applications est-il fait pour moi ? », ces qualités peuvent s’acquérir avec le temps et la pratique, mais sont essentielles pour développer correctement.

Une méthode de correction de bugs claire

Le premier élément manquant, c’est une méthode systématique.

Sans méthode, vous avancez à l’aveugle. Vous ne savez pas par où commencer, ni comment planifier votre démarche. Vous essayez des choses au hasard en espérant corriger votre bug.

Avec la bonne méthode, vous savez exactement quoi faire à chaque étape :

1. Isoler la zone de code responsable du bug
2. Formuler des hypothèses claires sur la cause possible
3. Tester chaque hypothèse de manière isolée
4. Corriger la cause réelle du bug à sa source

Les bons outils de diagnostic

Outre la méthode, il vous faut les bons outils pour tester vos hypothèses et comprendre le bug. Mais difficile de savoir lesquels utiliser sans formation.

Parmi les outils indispensables, on trouve notamment :

• L’intégration d’outils de journalisation (logging) dans votre code
• Un bon IDE avec un débogueur intégré

Apprenez la méthode complète de débogage

Dans cet article, je vous ai présenté la logique utilisée par les développeurs expérimentés pour diagnostiquer et corriger efficacement les bugs.

Mais connaître la logique ne suffit pas. Vous avez besoin de savoir comment l’appliquer concrètement :

• Comment configurer et utiliser un débogueur efficacement
• Quand utiliser les journaux plutôt que le débogueur
• Comment formuler des hypothèses pertinentes face à un bug
• Quelles étapes suivre du symptôme jusqu’à la correction

C’est exactement ce que j’enseigne dans mon livre Apprendre à programmer ses premières applications où j’ai dédié une partie entière aux techniques de débogage professionnelles avec :

• Un exemple concret de bug à diagnostiquer et à corriger
• Des explications détaillées sur chaque outil
• Comment exécuter la méthode en utilisant ces outils

Questions fréquentes sur le débogage

Combien de temps faut-il pour trouver un bug ?

Avec une méthode structurée et les bons outils, un développeur expérimenté peut diagnostiquer et corriger la plupart des bugs en 15 à 30 minutes. Les bugs complexes (erreurs de logique difficiles à reproduire, problèmes d’architecture) peuvent nécessiter quelques heures.

Dans de rares cas, le diagnostic peut s’étaler sur des semaines si le bug ne se manifeste que dans des conditions très spécifiques (événements rares, environnements, etc.).

Quel est le meilleur outil pour déboguer ?

Il n’y a pas un seul « meilleur » outil, les deux outils (débogueur et journaux) sont complémentaires et indispensables.

Ces outils servent à diagnostiquer les bugs mais sont plus ou moins adaptés selon le contexte. La difficulté réside dans le choix du bon outil au bon moment.

Comment éviter les bugs dans son code ?

La vérité ? Vous ne pouvez pas éviter tous les bugs. Même les développeurs seniors en produisent. Mais vous pouvez réduire significativement leur nombre et leur gravité en adoptant une démarche professionnelle dès le départ :

• Une bonne conception de votre application
• Des tests unitaires et d’intégration
• Si possible, une revue de code par des pairs

Conclusion

Votre code ne marche pas ? C’est normal. Tous les développeurs, du débutant au senior, passent par là quotidiennement. La différence, ce n’est pas le nombre d’erreurs qu’on fait (on en fait tous), mais la vitesse et l’efficacité avec lesquelles on les corrige.

Modifier au hasard, ajouter des traces partout, copier des solutions sans comprendre, etc. sont des approches qui ne fonctionnent pas. Elles vous font perdre du temps et génèrent de la frustration. Vous devez vous inspirer des professionnels qui adoptent une démarche scientifique pour diagnostiquer et corriger les bugs efficacement (analyse, hypothèses, tests et correction).

Si vous voulez enfin devenir autonome face aux bugs, et plus largement, adopter une démarche professionnelle pour développer vos applications, je vous invite à découvrir mon livre « Apprendre à programmer ses premières applications ».

Ainsi, la prochaine fois que votre code ne marchera pas, vous saurez exactement quoi faire pour corriger vos bugs efficacement.
C’est le moment de transformer votre approche du débogage.