Bonjour nal, à moitié bookmark,
Un « bug » informatique a causé un trop-perçu de 3,4 milliards d'euros pour des agriculteurs bénéficiaires de la PAC. La banque responsable de ces versements indique que « L'origine de ces incidents est strictement technique et non humaine ». Ah, ils ont des robots programmeurs maintenant ? (et encore, un robot est programmé par un humain…)
Ça me rappelle toutes les fois où on m'a indiqué que le problème « venait de la machine » afin de se dédouaner de leurs responsabilités. Quand est-ce que les gens (que ce soient les informaticiens ou leurs responsables) arrêteront de taper sur ces bêtes machines pour enfin assumer que oui, les machines sont fabriquées et programmées par des Hommes, et qu'on ne peut pas blâmer un tas de métal et de bits qui n'a rien demandé ?
Un des articles sur ce bug : http://www.lemonde.fr/economie/article/2013/12/08/bug-au-credit-agricole-les-primes-de-la-pac-doublees-pour-350-000-agriculteurs_3527525_3234.html
# Oui mais
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
Un être humain a été "créé" par ses parents, alors moi je suis pour qu'on blâme les parents du fautifs.
Euh.. wait.
[^] # Re: Oui mais
Posté par liberforce (site web personnel) . Évalué à 4.
Ça veut dire que les vrais responsables sont morts, ils l'ont bien cherché !
[^] # Re: Oui mais
Posté par Antoine . Évalué à 8.
C'est justement la différence entre création et procréation…
# le jour ou on blâmera le marteau
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Les gens assumeront peut être le jour ou l'on dira que c'est la faute du marteau, si on se tape sur les doigts, que le grand frère dira que c'est la faute du bilboquet si il a atterri sur la tête de son petit frère, ou c'est la faute du micro-onde, si la tête de la poupée de la petite sœur à fondu.
"La première sécurité est la liberté"
[^] # Re: le jour ou on blâmera le marteau
Posté par Maclag . Évalué à 4.
http://www.dailymotion.com/video/xldtq0_le-bureau-episode-1_fun
à 11:51
[^] # Re: le jour ou on blâmera le marteau
Posté par feth . Évalué à 5.
Bah, ce sont les voitures qui tuent les cyclistes et les piétons (autopromo).
[^] # Re: le jour ou on blâmera le marteau
Posté par hercule_savinien . Évalué à 4.
Sans remettre en cause ta comparaison pertinente, ça me fait penser à l'argument des pro armes à feu aux États-Unis :
« Ce ne sont pas les armes qui tuent les gens, ce sont les gens qui tuent les gens ».
Argument difficile à contrer. (Non, le fait que plus d'armes impliquent plus d'occasions ou plus d'accidents ne suffisent pas).
Le FN est un parti d'extrême droite
[^] # Re: le jour ou on blâmera le marteau
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Leur argument est facile à contrer. Il suffit de regarder leur taux d'homocides.
New York est connu pour avoir une baisse drastique du nombre de mort annuel suite à la politique de tolérance zéro d'un maire précédent. NY est devenu agréable à vive avec 213 meurtres en 2013.
La France, en entier, a moins de 700 homicides, par an en 2012.
"La première sécurité est la liberté"
[^] # Re: le jour ou on blâmera le marteau
Posté par Renault (site web personnel) . Évalué à 4.
Si tu veux être rigoureux, il faut compter les homicides par arme à feu par habitant et par an pour avoir une valeur intéressante. ;)
Après au niveau de la sécurité, il faut trouver un compromis entre la liberté et la sécurité, est-ce que détenir une arme à feux chez soit est une liberté utile : c'est discutable, et aux USA on le voit, il est très rare qu'un membre de la population s'en serve pour se défendre efficacement (en cas de massacre dans la rue, le temps de capter ce qu'il se passe, dégainer l'arme et viser…).
Avoir une arme à feu n'est pas très utile, et je pense que la France a un bon compromis en permettant à ceux qui veulent de le pratiquer dans un cadre strict : chasse ou club de tir sans que ça nuise à leur liberté de profiter du plaisir qu'ils éprouvent.
[^] # Re: le jour ou on blâmera le marteau
Posté par Larry Cow . Évalué à 10.
La justification fondamentale du droit de porter une arme aux E.U. (et ce qui fait que c'est le second amendement à la constitution, et pas un obscur texte de loi fédéral à la con sur l'auto-défense), c'est une question de souveraineté. Selon eux, le peuple est souverain, l'état (fédéral ou pas) n'est que le dépositaire temporaire de l'autorité. Si l'état part dans une direction qui n'est pas celle voulue par le peuple - et par exemple met en place une dictature - c'est à ce dernier que revient la responsabilité de remettre l'état sur le droit chemin. Pour ça, ils estiment qu'il vaut mieux laisser tout un chacun disposer d'armes à feux avant d'en avoir besoin, vu qu'après ça sera probablement plus difficile.
Tant qu'on considère le 2nd amendment comme lié à des questions de sécurité individuelle, on rate une grosse partie de la problématique, et on caricature un tout petit peu le débat.
Ceci étant, c'est intéressant de re-considérer cet aspect des choses dans un contexte PRISM-ien, où l'état outrepasse manifestement les missions qui lui sont confiées par le peuple souverain.
[^] # Re: le jour ou on blâmera le marteau
Posté par Renault (site web personnel) . Évalué à 3.
Non, pas du tout car finalement le contexte de la Constitution a radicalement changé.
Depuis l'état fédéral est doté d'une armée puissante, professionnelle, entrainée et bien mieux équipée que n'importe quel américain lambda. Si le peuple veut une guerre civile avec le gouvernement et gagner, je leur souhaite bonne chance mais je doute qu'ils y parviennent.
Cet argument était valable quand l'armée britannique et la milice américaine faisaient jeu égal en terme de rapport de force, ce n'est pas le cas ici.
Sans compter que de nombreux pays, même sans arme à feu disponible partout, ont pu renverser l'Etat.
Je suis conscient de l'importance dans la mémoire collective américaine de ce dispositif. Mais je pense qu'il est temps d'évoluer et d'essayer d'évaluer le gain et le coût… En tout cas en terme de perte de liberté pour un gain de sécurité c'est sans doute l'un des rares exemples valide (le reste est souvent bien illusoire).
[^] # Re: le jour ou on blâmera le marteau
Posté par dj_ (site web personnel) . Évalué à 6.
Vu les exemples récents, les citoyens américains savent qu'il y a moyen de faire bien mal a leur armée en cas de guerre civile (Afghanistan, Irak, …)
[^] # Re: le jour ou on blâmera le marteau
Posté par Maclag . Évalué à 3.
Oui mais du coup ils doivent bien voir aussi que ce faisant, il y a aussi moyen de SE faire mal quand l'armée riposte.
[^] # Re: le jour ou on blâmera le marteau
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
« Une milice bien organisée étant nécessaire à la sécurité d'un État libre, le droit qu'a le peuple de détenir et de porter des armes ne sera pas transgressé. »
Mais bon, transformer "free state" en question de souveraineté, c'est un peu rapide.
D'ailleurs, il suffit de voir les limitations que Obama n'arrive pas à faire passer. Il y a une classification des armes à feu : arme de point que l'on peut cacher, arme avec beaucoup de munitions (qui ne sert donc pas à la défense), l'arme de guerre, le fusil qui est visible et dispose de 2 coups.
Si le but est la lutte contre un état totalitaire, on peut faire disparaitre l'arme de poing et autoriser le missile antichar. Si on parle d'autodéfense, on peut interdire tout ce qui n'est pas visible (gros), et qui contient beaucoup de munitions.
"La première sécurité est la liberté"
[^] # Re: le jour ou on blâmera le marteau
Posté par feth . Évalué à 2.
Pour reprendre le parallèle avec les voitures qui tuent des cyclistes, si on appliquait « Ce ne sont pas les armes qui tuent les gens, ce sont les gens qui tuent les gens », il conviendrait de changer de formulation et d'écrire que des automobilistes tuent des voitures. Or on choisit de ne mettre en cause ni l'utilisation de la voiture ni les normes acceptables de pilotage d'engins massifs en zone résidentielle.
[^] # Re: le jour ou on blâmera le marteau
Posté par moi1392 . Évalué à 10.
Pas vraiment non… une arme à feu est faite pour tuer !
Pas un logiciel (en tous cas, pas un logiciel de compta…) ni un marteau, ni une voiture.
Après, effectivement, on peut tuer quelqu'un avec un marteau ou une voiture (ou un logiciel de compta pour chuck norris)
Mais vendre un objet dont le but est de tuer en disant que c'est pas la faute de cet objet mais des gens qui l'utilisent, et donc que sa vente ne pose pas de soucis en elle même, c'est un peu (sarcasme) se moquer du monde quand même…
[^] # Re: le jour ou on blâmera le marteau
Posté par Moonz . Évalué à -2.
Pas exclusivement, non. Une arme à feu peut être utilisée dans un objectif de dissuasion ou de neutralisation.
[^] # Re: le jour ou on blâmera le marteau
Posté par dinomasque . Évalué à 5.
Dissuasion = menacer de tuer
Une arme à feu est faite pour détruire (blesser ou tuer) et peut avoir des usages annexes (ouvrir une bouteille de bière : cf. l'épisode des Simpsons ou Homer s'achète un flingue et l'utilise pour tout et n'importe quoi).
BeOS le faisait il y a 20 ans !
[^] # Re: le jour ou on blâmera le marteau
Posté par Zylabon . Évalué à 10.
On peut se servir d'une grenade comme d'un presse papier aussi. Pour peu qu'elle soit utilisée par un médecin pour garder les dossiers de ses patients, les grenades sont bonnes pour la santé.
Please do not feed the trolls
[^] # Re: le jour ou on blâmera le marteau
Posté par ZeDuke . Évalué à 0.
Ou comme disait un certain Confucius : "Ce n'est pas le vin qui enivre, c'est l'homme qui s'enivre"
[^] # Re: le jour ou on blâmera le marteau
Posté par Pol' uX (site web personnel) . Évalué à 2.
« Les mauvais ouvrier ont toujours de mauvais outils. »
Adhérer à l'April, ça vous tente ?
# le fameux bug spatiotemporel
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 10.
Au hasard, le script, il serait pas dans la crontab entre 2h et 3h ?
(Dans la vie, y'a les root qu'on déjà rm -fr /* et ceux qui vont le faire.)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Et pourquoi pas ?
Posté par Blount (site web personnel) . Évalué à 10.
Oui les machines sont faites par les humains, tout problème est indirectement lié à l'humain.
Mais, ils n'ont pas forcément tord. Je pense que leur but est de différencier deux choses :
1 - le problème est lié à une tâche automatique d'un programme contenant un bug.
2 - un pinpin a écrit 3400000000 au lieu 3400000 dans le champ texte.
La différence entre les deux est que le point 2 suggère un problème lié directement à une personne ayant commise une erreur dans son action. Le point 1 suggère un bug technique.
" Ça me rappelle toutes les fois où on m'a indiqué que le problème « venait de la machine » afin de se dédouaner de leurs responsabilités "
Et quand tu as un bug provenant d'un logiciel dont tu n'es pas l'auteur et que d'ailleurs tu ne sais même pas comment il est fait puisque tu n'es pas développeur. Bin oui, ça vient bien de la machine et non de toi.
Bon, je ne défend pas la banque mais je trouve ton raccourcie un peu trop rapide. Il ne faudrait pas tout mettre dans le même sac ;)
[^] # Re: Et pourquoi pas ?
Posté par Anonyme . Évalué à 9.
les ordinateurs des banque sont des bon vieux VAX, avec des programmes en cobol :) sans bug.
je pense au point 2) avec une nuance, un pinpin lance l'ordre de virement, comme cela concerne plein de compte cela mets un peu de temps, le fameux pinpin habitué au virement qui dure max 10s et au ping de 17ms sous WoW pense que son ordre a foiré, bien que la moulinette soit lancé sur les 45 000 comptes. soit une dizaines de minutes.
son chef est au café, il relance une deuxieme fois la moulinette \o/ pour eviter de se faire engeuler.
comme le programme est en cobol mettre un verrou sur l'appli metier ne va pas etre possible, sans couter 250000 euros. Donc ca va recommencer plus tard \o/ avec d'autre.
Le post it sur l'ecran avec écris : attendre 45 minutes pour valider les virements, va partir à la poubelle dans les 6 mois.
[^] # Re: Et pourquoi pas ?
Posté par Padishah . Évalué à 1.
Oui, pour le cobol.
En revanche, coté système, c'est plutot du Mainframe IBM.
Les ordres de virement sont généralement lancés en batch. Donc j'imagine plutôt un fichier foiré avec doublonnage de lignes.
Le fichier a sans doute été envoyé par le donneur d'ordre.
[^] # Re: Et pourquoi pas ?
Posté par feth . Évalué à 5.
Bah c'est un décalage à gauche de tous les bits juste au moment de les transférer à cause d'un tremblement de terre et de radiations excessives.
[^] # Re: Et pourquoi pas ?
Posté par benoar . Évalué à 2.
Tor_t_. Le tort tue.
Tâche codée par un humain, qui a peut-être oublié de mettre un ! (not) dans sa condition (genre « if (virement_sepa) », rapport au commentaire plus bas qui parle plus précisément de l'origine), par exemple.
Bah voilà, c'est juste que dans un cas c'est un programmeur qui l'a mal tapé, dans l'autre un « banquier ».
Non, comme je l'ai montré.
Et bien tu blâmes le fournisseur de ton logiciel, qui ne pourra pas blâmer la machine mais un humain, et ainsi de suite.
# Eruption solaire
Posté par davandg . Évalué à 3.
Peut-être était-ce un bug hardware ?
[^] # Re: Eruption solaire
Posté par Xinfe (site web personnel) . Évalué à 3. Dernière modification le 09 décembre 2013 à 12:22.
Sans compter la complexité technologique qui peut faire qu'un bug se produise dans certaines conditions particulières. Au final, on parle bien d'électronique dans le monde réel à des dimensions nanometriques.
Si tout était parfait, les memtest n'existeraient pas !
[^] # Re: Eruption solaire
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Les machines IBM tiennent compte du rayonnement solaire pour leur taux d'erreur. Sur x86, la mémoire cache dispose de checksum ECC pour invalider une ligne en erreur.
"La première sécurité est la liberté"
[^] # Re: Eruption solaire
Posté par Kerro . Évalué à 1.
Là je suis très étonné.
As-tu un lien qui traÎne ?
[^] # Re: Eruption solaire
Posté par navaati . Évalué à 0.
C'est seulement sur les serveurs chers.
[^] # Re: Eruption solaire
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Tu confonds avec la RAM ECC.
"La première sécurité est la liberté"
[^] # Re: Eruption solaire
Posté par navaati . Évalué à 0.
Ah wep. J'avais lu trop vite.
[^] # Re: Eruption solaire
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je ne sais plus. Je bossais dans la microelectronique. Et au lieu de perdre des performances, ou d'augmenter la consommation des arrays de SRAM, il préfère mettre des codes de détections d'erreur qui génère quelques miss de temps en temps.
"La première sécurité est la liberté"
[^] # Re: Eruption solaire
Posté par Antoine . Évalué à 1.
Il vaut mieux corriger les erreurs aussi, si la ligne de cache est dans un état modifié.
[^] # Re: Eruption solaire
Posté par Kerro . Évalué à 5.
C'est juste que de mon point de vue de néophyte ça me semble étrange.
Pour qu'une somme de contrôle fonctionne sur une ligne de cache il est nécessaire de lire la ligne en totalité à chaque vérification (donc à chaque accès) Et de faire le calcul avant que l'instruction ne fasse une action. Il faut que ce soit en un seul cycle, sinon le cache perd beaucoup d'efficacité. C'est à ce niveau que je suis étonné parce que ça fait pas mal de transistors et pas mal d'énergie.
Je viens de regarder des docs Intel et AMD. Ça existe depuis au moins le Pentium III et c'est désormais très commun (je n'ai pas vérifié tous les processeurs, mais les quelques Intel et AMD que j'ai regardé l'on tous). Alors là franchement je l'ignorais totalement.
Ce n'est pas par ligne de cache, mais par mot. Là effectivement ça fait sens.
Le processeurs "bas de gamme" ne l'ont pas sur le cache L1.
Suivant les modèles c'est de l'ECC ou de la parité. Ça protège soit les données, soit les données + le TAG. Je ne saisi pas trop l'intérêt de l'ECC vu que les données non erronées sont dans la RAM et que ça doit être vraiment très très rare d'avoir un problème. Par contre avoir une somme de contrôle sur plusieurs bits me semble plus solide. Bon bref je ne connais pas les raisons de ces choix, c'est probablement fait correctement.
Exemple d'un Xeon E7-8800/4800/2800 :
Cache L1 pour les instructions : ECC avec capacité de correction d'un bit (pas d'info sur la capacité de détection)
Cache L1 pour les données : parité si 32 kib, ECC sur données + TAG si 16 kib (pas de précisions sur les capacités de détection/correction)
Cache L2 : ECC (pas de précisions)
Cache L3 : ECC avec capacité de correction de 2 bits (pas d'info sur la capacité de détection)
Merci pour l'info :-)
[^] # Re: Eruption solaire
Posté par Antoine . Évalué à 4.
Ben non, si le cache contient des données modifiées, les données non erronées ne sont pas dans la RAM :-)
(un cache, ça ne sert pas qu'en lecture)
# le Crédit Agricole, un expert de ces problèmes
Posté par palm123 (site web personnel) . Évalué à 4.
extrait de
http://www.europe1.fr/Economie/350-000-agriculteurs-touchent-deux-fois-la-PAC-1735305/
Pas une première. Par ailleurs, le 27 novembre "le même type d'incident avait déjà eu lieu", selon le journal. "Un prestataire du Crédit agricole d'Ile-de-France a viré en double les salaires de 8.000 salariés de France Télévisions. Au total, 94 millions d'euros ont été versés au lieu de 47 millions. Le bug a été résolu en quelques jours", assure le journal.
Le Crédit agricole a tenu à démentir "tout lien entre les deux incidents rapportés", et rappelle au passage qu'il "traite quotidiennement des millions d'opérations similaires dans de bonnes conditions".
ウィズコロナ
[^] # Re: le Crédit Agricole, un expert de ces problèmes
Posté par mazarini . Évalué à 2.
Un bug ? une erreur plutôt.
La banque de la boite ou bossait ma femme avait ranger la disquette (c'est vieux)) des salaires sans la traiter… sauf le coup de tampon "traité". La c'est sur que c'était pas un bug de la banque : ses programmes n'avaient pas vu les données.
[^] # Re: le Crédit Agricole, un expert de ces problèmes
Posté par rahan . Évalué à 10.
Pas mal le salaire net moyen chez France Télévisions…
[^] # Re: le Crédit Agricole, un expert de ces problèmes
Posté par rewind (Mastodon) . Évalué à 8.
Si tu enlèves Pujadas, il ne reste que 27 millions de salaires à distribuer…
# précision
Posté par fravashyo (site web personnel) . Évalué à 7.
En tout cas après les virements erronés (fait en double), les comptes ont immédiatement été redébité de la somme en trop, donc il n'y a pas eu à véritablement parler de "trop-perçu".
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
# faute avouée, faute à moité....
Posté par vlamy (site web personnel) . Évalué à 10. Dernière modification le 09 décembre 2013 à 14:58.
Mon passage préféré :
Ils ne sont pas joueurs quand même, ils ratent une occasion de bonne publicité et préfèrent passer pour des branquignoles. Moi une banque qui me verse mon salaire en double, je suis prêt à essayer.
# Bug de migration ?
Posté par GaMa (site web personnel) . Évalué à 5.
D'après le métro d'aujourd'hui (http://www.metronews.fr/info/systeme-de-paiement-sepa-attention-aux-risques-de-bugs/mmlh!ajs2OS0LFER5g/), il serait possible que ce bug soit lié à la migration au système de paiement commun à l'Europe (SEPA) basé sur les BIC/Iban plutôt que sur les RIB.
Matthieu Gautier|irc:starmad
[^] # Re: Bug de migration ?
Posté par jihele . Évalué à 10.
C'est bien dans l'air du temps que de considérer que les migrations sont responsables de nos problèmes.
Attendons-nous à une réponse ferme du Ministère de l'Intérieur.
# PEBCAK
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -4.
On indique que le problème se situe dans l'interface chaise-clavier. En anglais, cela donne PEBCAK. Le crédit agricole veut nous faire croire qu'aucun humain ne "signe" ces ordres de virement ?
[^] # Re: PEBCAK
Posté par mazarini . Évalué à 3.
Il y a généralement uniquement des contrôles de cohérence avec des enregistrement de début et de fin de fichier (nom du fichier, numéro de fichier, date du fichier, nb enreg, total montant).
Normalement, c'est le numéro de fichier qui permet de ne pas traiter le fichier 2 fois. Il arrive que l'on conserve les premiers enregistrements pour ne pas traiter le fichier 2 fois, mais avec des payes, ça ne doit pas être possible.
Je ne pense pas qu'il y ai de validations manuelles sur le traitement d'un fichier transmis par un client. Au mieux, quelqu'un saisie un montant de contrôle transmis par mail, mais ça doit être exceptionnel.
Enfin, on en voit des drôles, comme traiter un fichier d'opérations de bourse en production au lieu de test (donc 2 fois).
[^] # Re: PEBCAK
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Merci, c'est beaucoup plus clair. Donc si je duplique le fichier de paie, on sera payé 2 fois pour Noël ?
# Les hommes devant les machines
Posté par xavier dumont . Évalué à 6.
Ce qui manque dans ton analyse c'est la prise en compte de l'action des hommes devant les machines. Que ce soit au Crédit Agricole ou ailleurs, on fait beaucoup d'économies sur les hommes que l'on presse d'utiliser de manière de plus en plus intensive les machines. Qu'il y ait des conneries de faites, c'est humain justement et il ne faudrait pas l'oublier. En plus, ce qui est en cause, c'est une chaîne d'humains avec entre eux des machines qui n'en ont rien à cirer, pas étonnant qu'on ait quelques surprises de temps en temps.
Le problème de l'informatique c'est que les humains, à un moment ou à un autre ( conception ou utilisation ) sont tenus de penser comme des programmes et ça, c'est pas possible à 100%
HAL
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.