Le message qui n'attend pas de réponse
Dans le jargon des chantiers navals, il existe une expression pour désigner l'ouvrier qui repère une fissure sur une coque, la marque à la craie, et repart aussitôt à son poste sans attendre les instructions du contremaître. On pourrait en dire autant d'un pilote qui, découvrant un problème mécanique mineur en vol, le note dans le carnet de bord pour l'équipe au sol du soir sans dérouter l'avion. Le geste a un nom informel dans les cultures d'ingénierie logicielle : report and run. On signale, on documente, et on s'éclipse — sans rester pour débattre, sans revendiquer la suite, sans transformer une observation en obligation.
L'expression vient à l'origine du monde des correctifs de sécurité et des forums de développeurs open source, où un contributeur de passage repère une faille, ouvre un ticket avec les informations nécessaires à sa reproduction, puis disparaît — parfois littéralement, changeant même de pseudonyme. Mais réduire ce comportement à une anecdote de geek serait passer à côté de ce qu'il révèle sur nos façons de collaborer.
Le prix caché de rester dans la pièce
On enseigne, dans la plupart des cultures professionnelles, une norme implicite : celui qui soulève un problème en devient responsable. C'est une intuition morale compréhensible — on ne veut pas d'un monde où chacun jette des critiques sans en assumer les conséquences. Mais cette norme a un effet pervers largement sous-estimé : elle punit l'acte même de signaler. Si repérer un bug, une incohérence dans un budget ou une faille dans un raisonnement m'engage automatiquement à le corriger, alors j'ai une raison rationnelle de ne rien dire. Ou de le dire à moitié, en flou, pour ne pas être happé par la suite. Cette dynamique explique en grande partie pourquoi tant de dysfonctionnements restent invisibles longtemps après que quelqu'un les avait déjà remarqués. Le silence n'est pas toujours de l'indifférence ; c'est souvent un calcul de charge de travail.
Un système qui punit le messager finit par ne plus recevoir de messages.
Découpler l'observation de l'exécution
Le report and run répare cette faille en séparant deux actes que l'on confond trop souvent : détecter et résoudre. Ce sont deux compétences différentes, deux états d'esprit différents, et surtout deux quantités de temps radicalement différentes. Repérer une anomalie prend une minute d'attention. La corriger peut prendre une journée, une semaine, ou nécessiter une expertise que l'observateur n'a pas. En dissociant ces deux moments, on obtient un effet presque paradoxal : les gens signalent davantage, et plus tôt, précisément parce qu'ils savent qu'ils ne seront pas enrôlés de force dans la résolution. La légèreté de l'engagement initial devient la condition de sa fréquence.
C'est un principe que l'on retrouve, sous d'autres habits, dans des domaines très éloignés de l'informatique :
- Dans certains hôpitaux, le personnel est explicitement encouragé à signaler une erreur potentielle sans avoir à proposer immédiatement la solution — l'inverse ayant longtemps découragé les remontées.
- Dans l'aviation, le compte rendu d'incident est volontairement détaché de toute sanction ou obligation de résolution personnelle, pour que l'information circule sans filtre.
- Dans une équipe de rédaction, un relecteur peut signaler qu'un paragraphe « sonne faux » sans être tenu de le réécrire lui-même — il n'a pas la voix de l'auteur, seulement l'oreille du lecteur.
Un acte de confiance, pas de désengagement
Il serait tentant de lire le report and run comme une forme élégante de paresse — je te refile le problème et je m'en lave les mains. C'est mal comprendre le geste. Bien pratiqué, il repose sur une confiance précise : celle que le système en aval saura traiter l'information sans qu'on ait besoin d'en superviser chaque étape. Signaler puis s'éclipser suppose qu'il existe quelque part un carnet de bord, un tableau, une personne qui lira le ticket. Sans ce filet, le geste devient de l'abandon pur et simple, et le signal se perd dans le vide. C'est d'ailleurs la vraie différence entre report and run et le simple fait de se défausser : le premier suppose une infrastructure de réception — un endroit où le signal atterrit, un rituel qui garantit qu'il sera vu. Le second n'existe que dans l'esprit de celui qui l'émet.
Ce que cela change dans le travail au quotidien
Appliqué à une équipe ordinaire, ce réflexe change discrètement la texture des échanges. On cesse de traiter chaque remarque comme le début d'un projet. On accepte qu'une phrase glissée dans un compte rendu — « ce chiffre me semble faux », « cette formulation est ambiguë », « je ne suis pas sûr que ce process tienne à l'échelle » — puisse exister sans engager son auteur au-delà de son énoncé. Cela suppose en retour une discipline chez celui qui reçoit : ne pas se retourner vers l'émetteur en lui demandant « bon, alors tu t'en occupes ? », geste qui referme instantanément la fenêtre qu'on venait d'ouvrir. Le report and run n'est pas une excuse à la négligence. C'est une hygiène de l'attention : elle permet à chacun de rester un observateur fiable, sans avoir à devenir, à chaque fissure repérée, le responsable de la réparation entière du navire.
