Comment "ASI" a fait fuiter par erreur des notes de travail
Certain·es de nos abonné·es ont eu accès à des notes de travail concernant une enquête en cours. Nos explications, et nos excuses aux personnes concernées.
Abonnez-vous pour pouvoir commenter !
si vous êtes déjà abonné Connectez-vous Connectez-vous
Commentaires préférés des abonnés
Un classique pour tout ceux qui travaillent dans le logiciel ça : un problème/bug/code temporaire est livré en production.
Du coup, vous pouvez vous inspirer de ce qui est fait dans le monde logiciel pour contrer ça. Une des choses les plus simp(...)
ARG ! Il faut vite alerter Médiapart et mettre au piloris le fautif !
Errare humanum est, perseverare diabolicum
: )
Zut, je n'ai pas reçu les notes confidentielles. Voilà qui me laisse des regrets de ne pas m'être abonné à la newsletter. J'aime bien les trucs confidentiels (déformation professionnelle).
Derniers commentaires
J'ai tout revendu sur le Darkweb. J'ai pu m'acheter 23 grammes de pâtes, moitié farine de blé mou, moitié plâtre. Merci ASI, merci Daniel S (je ne cite pas nom, c'est confidentiel). J'attends la prochaine newsletter pour m'acheter 2,5 grammes de parmesan (moitié féta périgourdine, moitié colle à bois). Merci de me rendre l'inflation plus facile !
En somme, ça ne remet pas en cause l'excellence de votre travail. Comme dirait l'un : "les excuses, ce sont surtout les sources compromises qui devraient les avoir..." et comme dirait l'autre : "merci pour votre transparence".
Les excuses, ce sont surtout les sources compromises qui devraient les avoir...
Et oui je le dis souvent les ordinateurs et leur automatisme est souvent source d’erreur… dans tous les domaines.
Merci pour l'explication. Errare humanum est... ;-)
Merci de ces précisions, les excuses étaient ici nécessaires : les jours suivant cette erreur, les articles d'@si sur tel ou tel dysfonctionnement médiatique chez d'autres étaient beaucoup plus difficiles à avaler.
J'espère surtout que les sources grillées en subiront le moins de conséquences possibles.
(J'avoue néanmoins que, lisant partout qu'il y avait un problème, je me suis abonné à l'arrache à la newsletter pour espérer récupérer la version problématique. En vain, évidemment, et je n'en suis pas très fier. Mais ca serait hypocrite de la cacher, vu que je me joins ci-dessus au choeur des critiques contre cette erreur)
Une " affaire des fuites " ...., mais, transparente !
Oups...
Faute avouée à moitié pardonnée ? J'espère pour le site et pour les sources qu'il n'y aura pas de conséquence fâcheuse, et que parmi les 15000 destinataires de la newsletter, il ne s'en trouvera pas un ou une pour tirer profit de cette malheureuse erreur humaine...
Mais l'existence de cet article, aussi louable soit l'intention de transparence et d'honnêteté sous-jacente, révèle aux 15000 destinataires le potentiel sulfureux de la missive. Or combien d'entre eux ont pris ou prennent le temps d'ouvrir et de lire en entier la newsletter ? Cet article fait de la pub à des infos qui auraient dû rester confidentielles, et qui de ce fait vont s'ébruiter davantage. Mais ne pas en parler aurait été une faute professionnelle ,un manquement à la confiance envers vos lecteurs. Terrible dilemme...
Bon courage à l'équipe pour gérer le potentiel shitstorm qui s'annonce en coulisse !
Merci pour votre transparence.
Il démontre le sérieux et l'humilité de votre démarche.
Mes encouragements à DS et à toute l'équipe.
Soutien moral aux sources lésées par ce problème de logiciel.
Heureusement, ce genre d'erreur entrainant des conséquences fâcheuses ne peut pas arriver dans un certain domaine...
Si il n'y avait pas eu de publicité dans le forum, je ne me serais pas aperçu de l'existence de ces notes. Selon les jours je lis d'abord mes mails ou je vais faire d'abord un tour sur le site.
C'est drôlement compliqué, faut faire un arbre des causes. Là c'est une conjonction de 2 choses, écrire les notes directement sur l'article et non sur un brouillon, et ne pas avoir relu la lettre. (peut-être qu'il y a un troisième truc, mais j'ai rien compris la bascule et tout ça). Il suffit de corriger au moins une des deux choses. La question est y a-t-il eu un dommage au bout de cet enchainement?
La personne éventuellement reconnaissable a-t-elle ressenti qu'on l'a reconnu?
Moi j'ai reconnu personne, faut dire que je n'ai pas cherché à comprendre et j'ai mis le mail à la corbeille. De toutes façons il y a un dommage aussi pour DS, bah oui, son procédé secret est trahi.
en bas:
mal dormi?
initialesds, matinaute, etc.
bascule -> naissance d'une lettre
appli? on met des notes/mots et ça génère chronique? à voir
café?
Bah! Comme disent d'autres plus haut, ou plus bas; on fait au mieux mais, au quotidien, il est statistiquement impossible d’empêcher ça.
Une fois fait tout ce qu'on peut, il faut juste espérer que l'erreur ne tombe pas sur un truc hypersensible provoquant mort d'humains...
Murphy dégage!!! :-)
Un classique pour tout ceux qui travaillent dans le logiciel ça : un problème/bug/code temporaire est livré en production.
Du coup, vous pouvez vous inspirer de ce qui est fait dans le monde logiciel pour contrer ça. Une des choses les plus simples à mettre en place et à adapter pourrait être la revue de code. C'est a dire obliger pour pouvoir livrer, l'approbation d'un ou plusieurs collègues. Pour qu'une bonne r3vue soit fait, il faut du temps, donc il vaut mieux répartir les revues sur tout le monde (et pas juste le redac' chef qui peut être débordé ;) )
Bonne remarque : il n'existe aucun système permettant de se prémunir d'une telle erreur, si ce n'est essayer de faire mieux. C'est heureusement ce qu'ASI compte faire.
Oui un multi-contrôle s'impose, on n'est jamais à l'abri d'une erreur
et il s'en glisse encore bien trop souvent malgré une relecture
De tout cœur avec @SI
Pas sûr que le multi contrôle soit le mieux au final. La dilution de responsabilité pourrait engendrer un effet pervers. Chaque contrôleur se repose sur les autres et fait donc moins bien son boulot.
Pour ma part, j'ai fait l'expérience du contraire, chaque contrôleur voulant "faire mieux", dans une volonté peut-être un peu vaine de se différencier. En tous les cas, ceci est vrai dans certaines siences
Après contrôle : sciences :))
il y a aussi le fait qu'appliquer ce système peut ralentir le moment de publication de l'article. et il suffit qu'un des vérificateurs soit absent, malade, en congés, parti plus tot chercher son gosse, etc, pour désorganiser le truc.
faire des erreurs, ça arrive à tout le monde. je trouve ça bien qu'ASI communique dessus. si LCI faisait preuve d'autant de transparence ce serait sympa à voir.
En l’occurrence (je bosse dans le logiciel et travaille même pour un site de presse), il me semble que le mieux serait d'adapter la procédure humaine de rédaction de telle sorte que des notes confidentielles ne soient jamais enregistrées dans la base de données d'un site public. Mais bon de l'extérieur, je n'ai pas toutes les infos pour juger.
Dans l'article ils indiquent précisément qu'ils font déjà une relecture des articles, donc ce procédé est déjà en place. Simplement ils ne font pas une relecture exhaustive des newsletters créées à partir du contenu des articles.
Faire une relecture de la newsletter d'un article déjà relu, on ne peut pas reprocher que ce ne soit pas fait. Humainement, demander à quelqu'un de faire la relecture d'un même contenu 2 fois pour s'assurer qu'il n'y a pas d'erreur dans le second texte. Ça ne peut pas fonctionner, la seconde relecture serait nécessairement faite très superficiellement.
Pour faire des revues de code tous les jours, je comprends à quel point on peut laisser passer des erreurs. Et ce n'est pas tellement lié au fait d'être débordé, mais d'avoir une tâche annexe et rébarbative de vérification, parmi d'autres missions bien plus palpitantes.
J'ai bien ri.
Zut, je n'ai pas reçu les notes confidentielles. Voilà qui me laisse des regrets de ne pas m'être abonné à la newsletter. J'aime bien les trucs confidentiels (déformation professionnelle).
ARG ! Il faut vite alerter Médiapart et mettre au piloris le fautif !
Errare humanum est, perseverare diabolicum
: )
