Ce que la recherche des erreurs en informatique peut apprendre des sciences naturelles

Un message n’arrive pas. Le journal fournit un message d’erreur qui suggère immédiatement une explication. Vous vérifiez cette explication, trouvez des éléments qui semblent la confirmer et, après deux heures, il s’avère que l’explication était fausse et que les indices n’étaient que coïncidence.

Ce n’est pas une erreur de débutant, mais la règle. Et il est remarquable que notre secteur dispose rarement d’une méthode pour ce problème, alors qu’il en existe une depuis des siècles et qu’elle fonctionne remarquablement bien. Les sciences naturelles ont exactement la même tâche : déduire les causes à partir d’observations, dans des systèmes dont on ne maîtrise pas entièrement la vue d’ensemble.

Cet article transpose cinq principes fondamentaux de la méthode scientifique à la recherche d’erreurs dans le flux de messagerie. Les exemples viennent de la pratique, mais la démarche n’est pas spécifique aux e-mails.

Pourquoi la recherche d’erreurs en informatique est systématiquement vulnérable

Le flux de messagerie est une chaîne de systèmes qui ont chacun leur propre vue du même message : la passerelle, la couche de filtrage, le serveur de transport local, le service cloud, la boîte aux lettres de destination. Chaque message est rédigé du point de vue d’une seule couche.

À cela s’ajoute que les textes d’erreur sont des catégories génériques. Une même formulation décrit souvent des situations très différentes, car le système qui refuse ne connaît qu’une grille approximative. Les codes d’état étendus sont précisément conçus pour former des classes, et non pour désigner des cas individuels.

Un exemple : un service cloud a refusé un message en indiquant que l’expéditeur n’était pas autorisé à effectuer une remise sortante. La même formulation est apparue dans le même environnement dans deux configurations totalement différentes. Dans un cas, un système tentait de remettre via le service à un destinataire externe, donc une véritable tentative de relais vers l’extérieur. Dans l’autre, le destinataire était une boîte aux lettres normale du service, et seule le domaine de l’expéditeur était contesté.

Celui qui prend le texte au pied de la lettre cherchera la même chose dans les deux cas. Et comme le mot « sortante » y apparaît, on commence par chercher du mauvais côté.

Principe 1 : une hypothèse doit interdire quelque chose

Karl Popper a enrichi la philosophie des sciences d’une idée immédiatement utile pour la recherche d’erreurs : une affirmation n’est exploitable que si elle est réfutable. Une explication qui convient à tout résultat d’observation imaginable n’explique rien.

Transposé à la pratique : formulez votre supposition de manière à ce qu’elle comporte une prédiction qui peut être fausse. Non pas « quelque chose ne va pas avec le domaine de l’expéditeur », mais « si j’envoie le même message avec un autre domaine d’expéditeur par le même chemin, il arrivera ».

La seconde formulation a de la valeur, car elle peut être réfutée en cinq minutes. Vous pouvez alimenter la première avec des indices pendant des heures sans jamais en savoir davantage.

Un bon test : avant l’essai, demandez-vous quel résultat réfuterait votre hypothèse. Si aucun ne vous vient à l’esprit, vous n’avez pas d’hypothèse, mais une impression.

Principe 2 : une variable, tout le reste identique

Le cœur de l’expérience est le contrôle des variables confondantes. En pratique, c’est régulièrement l’inverse qui se produit : on compare deux cas disponibles par hasard. Or ils diffèrent presque toujours simultanément sur plusieurs caractéristiques.

Exemple réel : les messages provenant de example-test.com étaient refusés, tandis que ceux provenant de partner.example arrivaient. Les deux domaines différaient sur au moins quatre caractéristiques : leur appartenance à l’organisation, l’endroit où les e-mails sont hébergés, l’existence d’une politique d’authentification stricte et le chemin de soumission. Il est impossible de conclure quoi que ce soit à partir de deux points de données présentant quatre différences. Chacune des quatre explications convient.

Construisez donc vous-même la comparaison. Même point de soumission, même destinataire, même chemin, même moment, et exactement une caractéristique modifiée. Si vous soupçonnez le domaine de l’expéditeur, ne modifiez que celui-ci.

Principe 3 : sans essai de contrôle, le résultat ne vaut rien

C’est la partie que l’on préfère omettre, et c’est la plus importante. Dans la recherche clinique, le groupe de contrôle va de soi ; en informatique, on y renonce généralement, puis on s’étonne de résultats contradictoires.

Votre configuration de test doit d’abord reproduire l’erreur. Si vous ne pouvez pas reproduire le cas d’erreur avec vos propres moyens, un contre-essai réussi ne signifie rien. Peut-être que votre message de test fonctionne uniquement parce que vous le soumettez à un autre endroit que le système d’origine, ou parce qu’un contrôle ne s’applique pas du tout sur votre chemin.

Un test exploitable se compose donc d’au moins deux messages :

Si l’essai 1 n’échoue pas, votre configuration n’est pas représentative. Vous n’avez alors rien appris sur le cas d’origine, seulement sur votre configuration de test, et vous devez soumettre plus près de l’original.

Un exemple détaillé

Revenons au cas ci-dessus, anonymisé. Les messages d’un système n’atteignaient pas les destinataires dans le cloud, tandis que d’autres messages vers les mêmes destinataires arrivaient sans problème. Trois essais par le même chemin, vers le même destinataire, à quelques minutes d’intervalle :

L’essai 1 a reproduit l’erreur, la configuration était donc valide. L’essai 2 a montré que le problème dépendait du domaine de l’expéditeur et non du destinataire, de la boîte aux lettres, du routage ou des autorisations. L’essai 3 était le plus élégant : il vérifiait de manière ciblée l’explication alternative la plus évidente et l’a réfutée, car other-test.com appartenait à la même organisation tout en passant malgré tout.

Trois messages, dix minutes, et la cause était établie au lieu d’être supposée. Auparavant, plusieurs heures avaient été consacrées à des tentatives d’explication dont aucune n’a résisté à l’examen.

Principe 4 : réfuter est le véritable progrès

Une hypothèse réfutée donne l’impression d’un recul. En réalité, c’est la seule chose dont vous êtes certain. Les confirmations sont faibles, car une observation peut correspondre à plusieurs explications. Une réfutation rigoureuse élimine toute une branche de l’espace de recherche, durablement.

C’est précisément ici que le biais de confirmation agit le plus fortement. Lorsque vous avez une supposition, vous trouvez presque toujours quelque chose qui lui correspond. Dans l’analyse décrite ci-dessus, il existait une corrélation entre le refus et la question de savoir où le domaine de l’expéditeur héberge ses e-mails. Elle semblait convaincante, mais reposait sur deux points de données qui différaient sur plusieurs caractéristiques. Le troisième essai l’a invalidée.

Notez donc les explications réfutées avec la raison pour laquelle elles ont été écartées. Ce n’est rien d’autre qu’un carnet de laboratoire. Cela a deux effets : la personne qui reprend le cas plus tard ne s’engage pas dans les mêmes impasses. Et vous remarquez vous-même lorsque vous tournez en rond, car une idée déjà écartée revient sous un nouveau nom.

Dans la documentation, les points réfutés doivent figurer explicitement à côté de ceux qui sont établis. Un rapport qui ne contient que la bonne réponse cache la moitié du travail et invite à le refaire.

Principe 5 : connaissez votre échantillon

La source d’erreur la plus subtile est le biais d’échantillonnage, et en informatique il touche surtout les requêtes dont les résultats sont paginés.

Vous interrogez sept jours de suivi des messages, filtrez localement selon un critère et n’obtenez aucun résultat. La conclusion évidente est que ce trafic n’a pas existé. En réalité, vous n’avez filtré que la première page, qui, en cas de volume élevé, ne couvre que quelques minutes.

Le résultat correct est : non trouvé dans l’extrait. Il n’est pas : n’existe pas. La différence est la même qu’entre « aucun effet n’est démontrable dans notre étude » et « il n’y a pas d’effet ».

Deux solutions fonctionnent. Réduisez la fenêtre temporelle jusqu’à ce qu’une page la couvre entièrement, ce qui se reconnaît à l’absence d’indication de résultats supplémentaires. Ou parcourez toutes les pages, puis analysez les résultats.

Et il y en a une troisième, souvent négligée : pour déterminer si quelque chose n’arrive jamais, une vérification de configuration est supérieure à toute observation. Si un système ne possède aucune route vers une destination, il ne peut pas y remettre de messages, quelle que soit la fenêtre d’observation. C’est la différence entre un argument empirique et un argument structurel ; lorsque vous pouvez disposer du second, utilisez-le.

Le transfert : adapter la charge de la preuve à la réversibilité

Ici s’arrête l’analogie avec la science, et la perspective de l’ingénierie prend le relais. La recherche vise la vérité, l’exploitation vise une installation fonctionnelle. Il en découle un critère que la science ne connaît pas : l’effort de preuve dépend de la réversibilité de l’intervention.

Désactiver un connecteur est une commande, et l’annuler l’est tout autant. Des indices motivés suffisent donc, car une erreur se corrige en une minute et se remarque immédiatement. Supprimer ce même connecteur n’est pas réversible ; dans ce cas, il vaut la peine d’obtenir une preuve supplémentaire au moyen de la configuration du système homologue ou d’un rapport d’utilisation côté serveur.

Il en va de même pour les modifications de règles. Vous pouvez introduire avec peu d’éléments factuels une étape purement d’observation, qui journalise sans rien rediriger. Elle est sans conséquence et obtient précisément les données qui manquent pour l’étape décisive. Seule la modification qui peut retenir des messages exige des preuves solides.

Celui qui n’applique pas ce critère commet régulièrement les deux erreurs à la fois : il exige des semaines de preuves pour un changement qui pourrait être annulé en quelques secondes, et il active sans garantie quelque chose qui peut interrompre le trafic de messagerie.

Quand vous pouvez vous arrêter

Il existe un point où continuer à creuser ne crée plus de valeur : lorsque la correction est établie, mais que le mécanisme reste incertain.

Dans l’exemple ci-dessus, trois essais avaient établi que le domaine de l’expéditeur était le déclencheur, que tout le reste du chemin de messagerie fonctionnait et qu’il n’y avait pas de problème plus large. La raison précise pour laquelle le service cloud prenait cette décision en interne est restée inconnue. Cela n’avait aucune importance pour la correction, car celle-ci relevait de l’application émettrice.

Distinguez donc consciemment deux questions. Que dois-je modifier pour que cela fonctionne ? Et pourquoi le système se comporte-t-il ainsi ? Vous devez répondre à la première ; vous pouvez adresser la seconde au fabricant. Un dossier de support comportant trois essais contrôlés, des horodatages, des identifiants de messages et un contre-exemple fonctionnel a de toute façon bien plus de valeur qu’une description du symptôme.

C’est d’ailleurs aussi le point où science et exploitation peuvent être clairement distinguées. La science ne peut pas abandonner la question du mécanisme. L’exploitation doit la prioriser.

La version courte

Formulez vos hypothèses de manière qu’elles puissent échouer et demandez-vous à l’avance quel résultat les réfuterait. Ne comparez jamais deux cas disponibles par hasard ; construisez plutôt la comparaison en ne modifiant qu’une seule variable. Reproduisez l’erreur dans l’essai de contrôle avant de croire au contre-essai. Considérez les réfutations comme des progrès et consignez-les par écrit. Pour chaque requête, vérifiez si vous voyez l’ensemble des données ou un échantillon. Enfin, adaptez le niveau de preuve requis à la facilité avec laquelle l’intervention envisagée peut être annulée.

Les requêtes concrètes sont présentées dans Analyser le flux de messagerie Exchange : suivi des messages, journaux SMTP et connecteurs de réception. Si vous préférez configurer les commandes par clics plutôt que les saisir, vous les trouverez dans le Générateur de commandes.