Tout le monde sait ce qu’est un bogue sur un logiciel, mais un bogue au niveau management, cela existe aussi. Les conséquences peuvent être catastrophiques. Commençons par le Boeing 737 Max.
Le Boeing 737 Max est la dernière évolution du premier 737 sorti en 1967. Comme certaines caractéristiques ont été sensiblement modifiées, les concepteurs de l’avion ont décidé que le logiciel rattraperait les problèmes de stabilité. Par souci d’économie et pour concurrencer Airbus, Boeing a décidé d’aller vite, trop vite, en négligeant les principes fondamentaux du développement aéronautique qui ont permis à l’avion d’être le moyen de transport le plus sûr de tous.
Cette dépêche retrace également d’autres catastrophes, révélant les problèmes dans le processus de décision qui, bien souvent, éloigne les décideurs des alertes émises par du personnel compétent. Dans bien des organisations, les subordonnés sont incités à minimiser ce qui dérange la direction.
Sommaire
- Boeing 737 Max
- Ariane 5 vol 501 (vol inaugural)
- Challenger STS-51-L
- Columbia STS-107
- Le Vasa
- Autres catastrophes similaires
- Anneau de fer martelé
- Le Guide de terrain pour comprendre « l’erreur humaine »
- Voir aussi d’autres bogues
- Et dans votre organisation ?
Boeing 737 Max
L’avion en est à sa sixième version. Il a été rallongé et équipé de réacteurs plus lourds et surtout plus gros, qui, s’ils avaient été mis au même endroit, auraient raclé le sol. Comme on ne pouvait pas allonger le train d’atterrissage, il a fallu réaliser de nouveaux mâts de réacteur pour avancer et relever les moteurs. Le centrage, le centre de poussée et l’aérodynamique de l’avion ont été de ce fait sérieusement modifiés, ce qui change notablement son comportement en vol. L’avion a tendance à cabrer. Pour corriger cela un capteur d’assiette a été ajouté à l’avion, et un logiciel devait renvoyer le nez de l’avion vers le sol pour compenser.
Le logiciel était censé corriger le problème de conception. Ce logiciel était un pis‑aller qui a été mal étudié. Il est anormal qu’un système de commandes de vol électriques doive avoir besoin d’être désactivé.
La bonne démarche eut été de modifier les points d’ancrage des ailes, voire de les redessiner, tout comme le plan de dérive. En fait, c’était un nouvel avion qu’il fallait créer et qualifier. Or, Boeing voulait rattraper son retard sur l’A320neo qui se vendait bien. Et l’une des raisons était l’absence de formation supplémentaire pour les pilotes.
Pour compléter le tableau, Boeing n’a utilisé qu’un seul capteur d’incidence (pas de redondance). L’existence même du logiciel a été cachée aux pilotes, ainsi que le moyen de le désactiver en cas de problème, pour éviter de devoir faire une formation longue à ce nouvel avion et faire croire qu’il se pilotait exactement comme un 737 classique. Le but était d’avoir les mêmes avantages que l’A320neo.
Business Insider rapporte que lors d’une réunion plénière, un responsable avait déclaré que « les ingénieurs expérimentés n’étaient plus nécessaires dans l’entreprise » et qu’après l’incident, un porte‑parole a déclaré que « la sécurité était toujours au centre des préoccupations ».
Bilan : 346 morts, deux avions perdus, déjà un milliard de dollars de perte.
Boeing serait obligé de garer ses avions cloués au sol sur le parking de ses employés.
The Roots of Boeing’s 737 Max Crisis: A Regulator Relaxes Its Oversight.
Le cauchemar du 737 Max ne cesse de s’aggraver.
Ariane 5 vol 501 (vol inaugural)
La conception de la fusée Ariane 5 s’est basée sur des éléments d’Ariane 4, dont le boîtier des mesures de navigation (centrale inertielle). Notons qu’Ariane 4 était le lanceur réputé le plus fiable de son époque avec 97 % de succès sur quinze ans de service (116 lancements).
Afin de valider l’ensemble complet d’un système, l’Aérospatiale avait l’habitude de réaliser des « chaînes sur table », c’est‑à‑dire un montage en laboratoire de tous les équipements de la fusée reliés à des simulateurs de stimuli. Dans le cas d’Ariane 5, l’Aérospatiale l’avait budgétisé à 800 000 francs. Mais le CNES pensait que l’Aérospatiale voulait réaliser ces « chaînes sur table » uniquement pour avoir plus de rentrées financières. Pourtant, ce n’était pas un test optionnel, l’Aérospatiale avait bien cette pratique sur tous ses projets spatiaux. Donc, pour faire des économies, le CNES a décidé la réutilisation de certains éléments d’Ariane 4, la calibration d’Ariane 4 et l’absence des « chaînes sur table ».
Le résultat a été l’explosion de la fusée après quarante secondes de vol (vidéos 1 et 2). Heureusement, le vol 501 d’Ariane 5 n’a pas fait de victimes, mais a entraîné un retard de plus d’un an sur le programme. L’économie des « chaînes sur table » de 800 000 francs, a coûté mille fois plus, 800 millions de francs !
Et effectivement, les « chaînes sur table » effectuées par la suite ont montré la parfaite reproductibilité du phénomène. L’accélération d’Ariane 5 étant cinq fois plus élevée que celle d’Ariane 4, la valeur accélération est copiée dans un registre trop petit, ce qui provoque une interruption logicielle « integer overflow ». Le pire, c’est que cette valeur n’était pas utile dans le cadre d’Ariane 5 !
4, 3, 2, unité, feu… allumage… décollage.
Dès la phase d’accélération, les deux boîtiers issus d’Ariane 4 connaissent tous les deux l’interruption logicielle « integer overflow ». Et par conséquent, le gestionnaire d’interruption par défaut effectue un autotest, c’est‑à‑dire qu’il vérifie le bus de données en envoyant alternativement des 0x5555 et des 0xAAAA. Le modèle interne simulé fonctionne bien, quant à lui, mais le système de vote à la majorité donne raison aux deux boîtiers issues d’Ariane 4.
Tous les paramètres propulsifs sont normaux et la trajectoire est normale.
Le pilotage automatique prend les commandes à la trente‑septième seconde, il pense que les données qui circulent sur le bus sont des données valides de navigation et procède à une correction extrême de la trajectoire. Ce braquage brutal exerce une pression aérodynamique très élevée. Une partie de la structure de la fusée se désolidarise, ce qui déclenche son auto‑destruction.
Notons que ces boîtiers sont utiles pour réaliser des mesures quelques secondes avant le décollage, mais après le décollage, ils ne sont plus d’aucune utilité. Ces boîtiers sont pourtant restés actifs pendant le décollage car c’était une exigence d’Ariane 4. Leur désactivation était prévue 40 secondes après le décollage, soit quelques secondes après le braquage de la fusée. Depuis, il y a une vraie chasse au code mort (le code inutile) dans les logiciels embarqués critiques.
Code source Ada du boîtier
Variable Biais Vertical BV
Nous avons bien le test des bornes -32768..32767 avant copie dans le registre 16 bits :
L_M_BV_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) *
G_M_INFO_DERIVE(T_ALG.E_BV));
if L_M_BV_32 > 32767 then
P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#;
elsif L_M_BV_32 < -32768 then
P_M_DERIVE(T_ALG.E_BV) := 16#8000#;
else
P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
end if;Variable Biais Horizontal BH
La valeur est copiée directement dans le registre 16 bits sans protection. Le rapport d’enquête indique que certaines variables n’étaient pas protégées pour éviter que la charge du processeur dépasse les 80 %. Aucune information n’a été trouvée pour justifier de protéger telle variable plutôt qu’une autre.
P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S
((1.0/C_M_LSB_BH) *
G_M_INFO_DERIVE(T_ALG.E_BH)));Enquêtes
Un contributeur de LinuxFr.org qui travaillait au projet Ariane 5, nous indique que seulement quelques heures après l’échec du lancement, les équipes d’Aérospatiale avaient déjà repéré des signaux d’erreur en ASCII qui circulaient sur le bus de données et que le pilotage automatique avait pris cela pour des données numériques valides.
Le CNES met immédiatement en place une commission d’enquête qui donne ses conclusions un mois après. Le rapport officiel démontre que les concepteurs du calculateur de la trajectoire ont volontairement exclu la spécificité d’Ariane 5. Lire aussi cette version anglaise et cette autre version anglaise.
Cette commission d’enquête officielle est composée d’ingénieurs en logiciel, et conclut à un problème logiciel. Deux autres enquêtes indépendantes remettent davantage en cause les erreurs de gestion du programme (le lien vers le PDF est cassé). Gérard Le Lann (INRIA) conclut à un problème d’intégration système. Jacques‑Louis Lions parle d’erreur de spécification et de conception logicielles. Quant à Mark Dowson, il insiste sur l’environnement de travail comme étant les racines de l’échec :
- carriérisme des managers et aspirations politiques de leurs décisions ;
- pressions sur les budgets ;
- pressions sur les délais ;
- culture du « pas cassé, pas corrigé » (If it’s not broken don’t fix it).
Alors, le problème d’Ariane 5 était‑il un bogue logiciel comme en conclut la commission d’enquête officielle, ou alors un bogue managérial ? Dans tous les cas, aucun manager n’a été inquiété. En revanche, les développeurs, eux, ont eu du pain sur la planche.
Challenger STS-51-L
L’accident de la navette spatiale Challenger a aussi pour origine la volonté de faire des économies sur le délai et le budget. Les personnes prenant ces décisions ont tendance à ignorer les alertes des ingénieur·e·s et physicien·ne·s car n’apprécient pas être remises en cause. C’est malheureusement un comportement humain répandu, qui devient un défaut fatal quand on a un poste de grande responsabilité.
L’accident a eu lieu 73 secondes après le décollage, entraînant la mort de l’équipage dont une institutrice qui devait donner un cours depuis l’espace et devenir la première « passagère de l’espace », tout un symbole. La médiatisation de ce coup de communication rendit le drame plus insoutenable car 48 % des élèves américains de neuf à treize ans regardaient le décollage depuis leur école.
L’équipage a probablement survécu à la désintégration du vaisseau et serait dans ce cas décédé lors de l’impact de la cabine avec la mer. La navette spatiale américaine avait été conçue sans système de sauvetage au décollage, en se fondant sur l’hypothèse que la navette spatiale devait abaisser le risque couru par les astronautes au même niveau que celui des passagers des avions.
L’accident a entraîné la mort de sept personnes, la perte du vaisseau, et une interruption de trente‑deux mois du programme de la navette.
En complément : la vidéo de Stardust « La destruction de la navette Challenger » (durée : 14 minutes).
Columbia STS-107
Le 1ᵉʳ février 2003, après quinze jours passés en orbite basse, la navette spatiale américaine Columbia se désintègre lors de sa rentrée dans l’atmosphère terrestre.
En août 2003, dans son rapport final, la Commission d’enquête sur l’accident de Columbia détermine que la cause directe de l’accident fut l’impact sur l’aile gauche de la navette d’un morceau de mousse isolante qui s’était détaché du réservoir externe lors du décollage. Le bouclier thermique de la navette étant endommagé, le vaisseau fut détruit lors de la rentrée atmosphérique en retour de mission.
Mais les causes de l’accident sont aussi d’ordre organisationnel. Ce problème de débris de mousse isolante était déjà connu des ingénieurs, mais les missions ont continué parce que les impacts étaient considérés comme inévitables et sans solution (« S’il n’y a pas de solution, c’est qu’il n’y a pas de problème. » — Jacques Rouxel in Les shadoks).
Aussi, après le décollage, plusieurs responsables veulent obtenir des images de la navette pour étudier les dégâts potentiellement provoqués par l’impact, mais se voient refuser leurs demandes pour des raisons de délais ou de budget. Ils se voient également reprocher d’avoir contourné la hiérarchie et de ne pas respecter la bureaucratie de la NASA.
Résultat : sept morts supplémentaires, une navette supplémentaire détruite, interruption du programme de la navette pendant vingt‑neuf mois, et suspension de la construction de l’ISS.
Références
- Columbia STS-107 – Chronique d’une catastrophe annoncée ;
- vidéo de Stardust « La destruction de la navette Columbia » (durée : 13 minutes).
Le Vasa
Cet énorme vaisseau, le Vasa, a sombré en 1628 lors de sa sortie inaugurale après seulement 1 600 m de navigation. On ne pouvait pas incriminer le logiciel à l’époque et même si, près de quatre siècles plus tard, la perception d’une construction bâclée et d’un chantier désorganisé sont à l’origine du syndrome de Vasa.
Les responsabilités sont difficiles à cerner et semblent diluées tout au long de la construction. Beaucoup d’éléments semblent concourir à l’aboutissement d’un bateau instable :
- les demandes de modifications faites par le roi de Suède pendant la construction, notamment les 72 canons qui étaient trop nombreux pour tenir sur un seul pont ;
- les changements de direction de la construction navale ;
- les délais et les questions économiques du fait de la perte de dix navires en une seule tempête ;
- les tests de navigabilité négligés.
Résultat : trente à cinquante personnes périrent avec le navire et, par ailleurs, ce naufrage du Vasa fut un véritable désastre financier pour le petit État suédois.
Autres catastrophes similaires
- mauvaises décisions lors de la construction du dirigeable britannique R101 qui s’écrase à 80 km au nord de Paris ;
- volonté des dirigeants d’arriver en avance et naufrage du Titanic ;
- déni d’erreur du commandant de bord et mauvaise procédures de secours lors du naufrage du Sewol.
Anneau de fer martelé
L’histoire commence avec l’ambitieuse construction du pont de Québec en 1903 : le plus long pont de type porte‑à‑faux au monde. La construction débute sous la direction d’un ingénieur originaire des États‑Unis (Theodore Cooper). À cause d’erreurs de calcul, le poids réel du pont excède sa capacité portante. Des problèmes furent remarqués par les ingénieurs canadiens, mais la direction ne tient pas compte de la gravité de la situation. En 1907, un ingénieur responsable demande l’arrêt complet des travaux, mais les travaux continuèrent. Deux jours après, 20 000 tonnes d’acier croulent dans le fleuve, et soixante‑seize travailleurs (sur cent) sont tués. À marée basse, la ferraille provenant de cet effondrement est visible sur la rive du fleuve. Le pont connaît un second effondrement en 1916, provoquant treize décès. L’année suivante, le pont est enfin achevé.
Suite à ces incidents, en 1922, l’ingénieur Haultain propose un rite d’engagement solennel qui oblige les ingénieurs à un comportement professionnel exemplaire. La même année, la Société des Sept Gardiens est créée et procède à sa première cérémonie en 1925 en remettant un anneau de fer martelé à chaque ingénieur. Si l’ingénieur abandonne son serment, il doit rendre l’anneau.
Le Guide de terrain pour comprendre « l’erreur humaine »
Pour aller plus loin, le livre The Field Guide to Understanding “Human Error”, troisième édition par Sidney Dekker (CRC Press, novembre 2017, ISBN 9781317031833).
Voir aussi d’autres bogues
- 1980 — Le système NORAD déclenche, à deux reprises, à trois jours d’intervalle, une fausse alerte d’attaque nucléaire, et, à chaque fois, les bombardiers chargés de bombes nucléaires décollent pour la contre‑attaque. En fait, le logiciel ne gérait pas la défaillance électrique.
- 1983 — Un satellite soviétique déclenche une fausse alerte d’une attaque de missiles, mais heureusement, l’officier russe n’y croit pas.
- 1983 — Le Vancouver Stock Exchange corrige son index de 525 à 1099 à cause d’une erreur d’arrondi passée inaperçue pendant quelques années.
- 1985 — La NASA ne détecte aucun trou d’ozone pendant sept ans car les grandes variations dans les mesures ne sont pas prises en compte.
- 1993 — Bogue du Pentium sur les nombres flottants.
- 1998 — Désintégration de Mars Climate Orbiter car une fonction utilise l’unité livre‑force (système anglo‑saxon) au lieu du newton. Pourtant, les projets de la NASA sont censés utiliser le système métrique.
- 2010 — Toyota rappelle un million de véhicules mais ce n’est pas la mécanique qui est en cause, plutôt le code spaghetti bourré de négligences.
- 2012 — Knight Capital Group met en production un automate de trading haute fréquence qui exécute, par erreur, un code de test faisant perdre à l’entreprise 440 millions de dollars en 45 minutes, soit 90 millions de plus que son capital, plongeant son cours de bourse de 75 %. Pour l’anecdote, KCG a réussi à renaître de ses cendres en levant 400 millions (4 jours après), puis revend ses logiciels KCG Hotspot à BATS pour 365 millions (2015), enfin KCG Holdings est valorisé à 1,4 milliard (2017) lors du rachat par Virtu Financial !
- 2014 — Apple a dans son code source deux lignes successives «
goto fail» ce qui a conduit à l’ajout de l’option-W misleading-indentationà GCC 6 (lire aussi le journal). - 2015 — Valve Steam dont son script d’installation pouvait effacer tout le
$HOMEsous GNU/Linux.
Et dans votre organisation ?
Reconnaissez‑vous des aspects de vos projets ? Partagez vos propres expériences dans les commentaires.
Aller plus loin
- Le Boeing 737 Max et le logiciel (100 clics)
- Rapport d’enquête du vol 501 d’Ariane 5 (39 clics)
# La fausse alerte soviétique de 1983
Posté par Jona . Évalué à 10.
L'officier russe qui a évité l'incident en 1983 s'appelle Stanislav Petrov.
Un thread Twitter relatant l'affaire:
https://twitter.com/Benazdia/status/1197266043745554440
[^] # Re: La fausse alerte soviétique de 1983
Posté par Funix (site web personnel, Mastodon) . Évalué à 9.
A ce sujet voir le documentaire en replay sur Arte par là https://www.arte.tv/fr/videos/039911-000-A/guerre-froide-l-homme-qui-sauva-le-monde/
https://www.funix.org mettez un manchot dans votre PC
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Un exemple du quotidien
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
Dans mon travail, en lien avec une grande école d'ingénieur (l'ensicaen) on trouve, ce me semble, deux beaux exemples de telles décisions.
La première c'est que cette école — contre tous les avis que j'ai pu entendre s'exprimer du moins ; précisons toutefois que je ne suis guère sociable et tout en bas de la hiérarchie, juste en dessous des techniciens de surface et des opérateurs de gardiennage — a décidé de faire classer plusieurs de ses laboratoires en ZRR (zone à régime réstrictif). Décision quelque peu contestée par des gens qui n'ont rien de plus urgent (à l'instigation instante et insistante de leurs instances dirigeantes) que de publier toute avancée scientifique qu'ils feraient — voire envisageraient de faire, diraient les mauvaises langues pour railler la course actuelle à la publication. Pourquoi pas. Une telle décision peut sûrement se justifier, même s'il s'agit essentiellement d'un (léger) fardeau administratif et d'un surcroît de carcan technique dans un contexte où les gens se sentent parfois obliger de démissionner ou de prendre des vacances pour disposer de temps pour… faire leur travail. Par exemple recruter et former des stagiaires — c'est l'une de nos missions les plus ingrates — devient plus compliqué ; surtout s'il s'agit d'étrangers nécessairement perçus par l'administration comme potentiellement plus malveillants ; n'y voyez pas de xénophobie institutionnelle.
Mais c'est une seconde réforme quasi simultanée qui rend tout cela cocasse et digne d'être mentionné ici : la grande école d'ingénieur abandonne la gestion de ses propres systèmes informatiques — peut-être était-ce trop chère, cela réclamait un véritable ingénieur — pour faire transiter son infrastructure sur celle dans les nuages d'un GAFA (mirosoft pour ne pas le nommer), particulièrement empressé à fourguer ses solutions pour accoutumer les jeunes générations. Cela signifie que non seulement toutes les données personnelles, déjà largement diffusée via w10 [*], mais aussi les courriels, et de nombreux documents de tous les personnels — de recherche inclus — ne seront plus guère protégés des yeux étrangers les plus susceptibles de s'y intéresser que par la promesse formelle et stipulée par contrat que « non, non jamais nous n'exploiterons ces données ; ou alors très discrètement. »
Bel exemple de cohérence dans les décisions, n'est-il pas ?
[*] OK. w10 est sorti depuis belle lurette, qui se préoccupe encore des quelques fuites mineures qu'il pourrait occasionner ? Tout cela ne tient-il pas d'un passé aussi mythique que les légendes d'age d'or, ou la cosmogonie Grecque ? Certainement pas les managers de la politique de sécurité renforcée de l'ensicaen apparemment.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Un exemple du quotidien
Posté par lym . Évalué à 9.
Pourtant, il y a 25 ans, une personne faisait très bien ce travail seule en plus de pas mal de TP d'enseignement:
http://patrick.ducrot.free.fr
Et pour la sécurité, je me souviens encore de ses images "Wanted" balancées régulièrement sur tout le réseau de machines Unix (servant à l'enseignement) visant avec humour le seul élève ayant réussi (pas bien longtemps, juste le temps de repérer un process inconnu rapidement décortiqué) à lui piquer son login. Le petit malin avait exploité (de mémoire) une faille liée au lecteur de disquettes 5"1/4 mis à dispo des élèves pour transférer leurs sources/fichiers de leurs PC perso, pour ceux qui en avaient…
Moi je n'avais pas fait si bonne pêche, avec mon chalut lancé à la même époque côté réseau PC (sous windows 3, de mémoire, à l'époque? Ils servaient alors à la bureautique) qui avait eu a peu près tous les élèves mais pas lui: Trop prudent déjà vis à vis des produits Microsoft, je pense qu'il ne se connectait que de son bureau avec sa machine, ce qui le rendait insensible à mon exploitation de l'ancêtre des services runtime UEFI: Les interruptions BIOS qui permettaient de mettre des hooks (tel un virus de secteur de boot, capacités de réplication en moins) sur les frappes clavier (permettant de récupérer tout ce qui suivait un mot clef type "login", "telnet"…) et accès disque (pour sauver cela, à des fins de glanage ultérieur, sur des zones de HDD inutilisées/cachées à l'OS). Un article cocasse dans le canard de l'école dont je dois toujours avoir copie quelque part avait cloturé ma 3ème année, exposant les mots de passe simplistes ou tout simplement drôles.
C'est triste de voir un Microsoft pourtant en perte de vitesse (hors bureautique et cloud) noyauter ainsi l'enseignement et la recherche. Mais dans le privé c'est pareil, y compris chez LE concurrent de Boeing: S'ils veulent refaire leur retard, au moins, ils n'auront pas à faire comme les Chinois qui avaient acheté un A320 qui ne s'est ensuite jamais montré dans aucun aéroport et n'a pas été revu en vol après sa livraison.
Pourtant, tous les produits et services de Microsoft sont plus que jamais évitables.
[^] # Re: Les décisions absurdes
Posté par Tonton Th (Mastodon) . Évalué à 10.
https://fr.wikipedia.org/wiki/Paradoxe_d%27Abilene
[^] # Re: Les décisions absurdes
Posté par Nitchevo (site web personnel) . Évalué à 10.
Voir aussi le "Les stratégies absurdes" :
https://www.melchior.fr/note-de-lecture/les-strategies-absurdes-comment-faire-pire-en-croyant-faire-mieux
Ou comment dans un monde gouverné par des indicateurs variés, tableaux de bord et indices de performance, l'ensemble de ces outils conduisent à un comportement au mieux sous-optimal et parfois franchement contre productif.
[^] # Re: Les décisions absurdes
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Très bon lien !
Je me souviens d'une histoire soviétique. Le gouvernement avait décidé de récompenser la seule industrie soviétique qui avait réussi à tenir les objectifs de productivité du Plan.
C'était une usine qui fabriquait des chandeliers (oui, pour mettre des bougies). Elle avait réussi à augmenter sa production conformément aux objectifs donnés à la métallurgie. Au bout de quelques années, ne pouvant augmenter la cadence de production des chandeliers, ils en ont augmenté la taille et donc le poids. Comme leur production était évaluée en kg, ils ont continué année après année à faire des chandeliers de plus en plus gros dont personne ne voulait et qu'ils entreposaient dans une aire de stockage.
On ne pouvait rien leur reprocher, mais je crois qu'ils n'ont pas reçu la récompense !
[^] # Re: Les décisions absurdes
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Je connaissais la même mais avec une miniaturisation de la production pour augmenter le nombre d’unités. Évidemment les sacs / voitures / … miniatures étaient bien moins utiles. Toutefois, je me demande ce qui relève de la propagande dans ces histoires.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par SChauveau . Évalué à 10. Dernière modification le 27 août 2020 à 17:57.
C'était il y a un peu plus de 20 ans pendant ma thèse où j'écrivais un compilateur en C++ pour un langage de type Matlab. J'ai perdu un temps fou à déterminer pourquoi certains programmes ne donnaient pas des résultats corrects. Après de nombreuses journées à me taper la tête contre les murs, j'ai finalement trouvé le bug qui se trouvait dans un switch-case ressemblant à ceci:
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
C'est plus visible en activant la coloration syntaxique C++ (ici sur LinuxFr.org ou dans Vim par exemple).
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par SChauveau . Évalué à 8.
En effet et si ma mémoire est bonne, ce bug m'a convaincu de changer pour un éditeur de texte supportant la coloration syntaxique (pendant les années 90, cela n'était pas aussi courant qu'aujourd'hui).
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 28 août 2020 à 08:04.
Trouvé aussi ! Bon, je voudrais commenter un truc mais ce serait un spoiler :)
Chaud. Tu me dis pas "il y a un bug dans cette zone", je ne trouverai jamais.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par pif17 . Évalué à 2.
Il y a un warning pour ça maintenant dans gcc.
La première fois avec ce bug est vraiment douloureuse.
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par Graveen . Évalué à 2.
Pareil, j'aurais validé "de visu" :D
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par Yth (Mastodon) . Évalué à 2.
En effet, c'est bien planqué !
À noter qu'un éditeur de code permet de repérer cette erreur immédiatement.
Ça donne à réfléchir sur notre dépendance à nos outils…
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par claudex . Évalué à 8.
Je l'ai eu avec une règle ipsec (de mémoire) dans openbsd:
La règle n'était plus appliquée :/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par jnanar (site web personnel) . Évalué à 3.
N'étant pas un développeur C++, je suis curieux de comprendre ce qui cloche ici.
Je continue en rot13 pour ne spoiler personne.
Rfg-pr dhr p'rfg yvé à y'bcéengrhe ovgjvfr KBE pvepbasyrkr ? Znvf pbzzr vy rfg qnaf ha pbzzragnver, w'nv qh zny à pbzceraqer pbzzrag çn cbheenvg êger yn fbyhgvba. Yn pbybengvba flagnkvdhr ar zr qbaar cnf ornhpbhc q'nhgerf vasbezngvbaf. Zrepv q'épynvere zn ynagrear :-)
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Créé un commentaire contenant le code en question, en utilisant la balise
et prévisualise-le (pas besoin de le soumettre).
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par chimrod (site web personnel) . Évalué à 3.
Aba, vy f'ntvg qh pbzzragnver qr yn Yrsg Qvivfvba dhv qéobeqr fhe yn yvtar fhvinagr. Cne pbafédhrag, yr oybp pnfr rfg whfgr éinyhé n oernx
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par aiolos . Évalué à 2.
Cbhe ceépvfre ha crh : vy f'ntvg qh pnenpgèer nagvfynfu dhv fvtavsvr dhr yn yvtar fhvinagr snvg ra snvg cnegvr qr yn zêzr yvtar. Çn crezrg qr pbhcre yrf yvtarf à 80 pnenpgèer cbhe yn yrpgher uhznvar, znvf cnf cbhe yr pbzcvyb.
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Il aurait suffit d'ajouter un caractère espace après l'antislash. Ce ne se serait pas vu et la ligne suivante ne serait pas passée en commentaire.
J'ai eu la chance de trouver le bug en 30s mais c'est en activant la coloration syntaxique que j'ai pu le vérifier.
Pour ceux qui n'auraient pas saisi le texte mystérieux, c'est du ROT13.
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par 2PetitsVerres . Évalué à 4.
Ah, je vois l'erreur, en MATLAB quand on fait une "division", ce qui se passe derrière n'est pas simplement "a/b", mais une résolution d'un système d'équation ! Comme ceci :
Comment, c'était pas ça ? (En vrai, c'est un joli bug :-p )
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par SChauveau . Évalué à 5.
En effet, la sémantique de l'opérateur \ de Matlab est beaucoup plus complexe que dans mon exemple mais mon bug se trouvait dans une routine d'optimisation du cas particulier où les 2 opérandes sont des scalaires connus à la compilation. C'est cela qui le rendait difficile à détecter car quasiment personne n'utilise l'opérateur '\' dans les expressions scalaires. Et bien sûr, je n'avais pas écrit de test pour ce cas particulier.
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par FLOZz (site web personnel) . Évalué à 1.
Ah oui ! Ça m'a pris un moment à capter ! :D
[^] # Re: Le bug idiot qui m'a pris la tête pendant 15 jours
Posté par Selso (site web personnel) . Évalué à 1. Dernière modification le 26 septembre 2020 à 13:27.
A part le risque de la division par 0 qui n'est pas contrôlé dans le bloc je n'ai pas trouvé avant de mettre la coloration syntaxique. D'où son intérêt !
L' '\' je le connais mais le commentaire m'a vraiment masqué son problème.
Je vais l'envoyer au collègue ;)
# A propos du Boeing 737.
Posté par xavier philippon . Évalué à 10.
Pour la petite histoire, il faut savoir qu'à l'origine en 1967, le Boeing 737 était volontairement court sur patte.
L'objectif était de pouvoir être utilisé sur des aéroports sommairement aménagés, avec des escaliers mobiles de faible hauteur ou intégrés à l'avion en option.
L'idée était bonne mais ne s'est pas révélée payante sur le long terme. Elle a complexifié la monte de moteurs modernes avec les conséquences que l'on sait.
Autre point, en 1967, ce type d'avion se devait d'être naturellement stable. Cet comportement augmente la trainée et donc la consommation.
Son concurrent, l'A320 conçu 20 ans plus tard, est prévu dès le départ pour intégrer des moteurs avec soufflantes de grand diamètre. Il est également conçu pour avoir des commandes électriques et une assistance au pilotage qui compense son instabilité relative. Instabilité qui est une conséquence de la diminution de trainée et donc de la consommation.
Conclusion, Boeing aurait du développer bien plus tôt un vrai nouvel avion pour remplacer le 737 mais Airbus a eu de la chance car les débuts de l'A320 n'ont pas été exempts de problèmes et de crashs meutriers.
[^] # Re: A propos du Boeing 737.
Posté par fortytwo . Évalué à 10.
Airbus a fait traditionnellement le choix sur toute sa gamme de mâts réacteur plus longs pour limiter l'interaction de la nacelle moteur avec l'aile. Cela favorise l'aérodynamique au détriment de la masse du mât. Il n'y a pas forcément de bon ou mauvais choix dans l'absolu, il s'agit de compromis influencés par la culture et le savoir-faire propre à chaque entreprise.
Il est clair que la famille 737 avoue son âge par rapport à celle de l'A320. Mais il s'agit encore de compromis, ici entre l'efficacité optimale et les coûts de conception qui sont évidemment bien plus importants pour concevoir un tout nouvel avion. Un investissement moindre permet de vendre moins cher, donc il peut y avoir deux équilibres économiques différents offrant de la place aux deux concepts. D'ailleurs Airbus aurait les technologies pour remplacer l'A320 par un modèle plus efficace, mais à un coût difficile à absorber surtout après quelques semi-échecs commerciaux (A340, A380).
Ceci à condition que la sécurité soit à peu près identique, or le B737 a traîné d'autres tares comme le défaut de gouverne de direction.
Comme souvent, les catastrophes ne sont pas le résultat d'erreurs uniques mais d'enchaînement de défaillances. On peut ajouter aux mauvais choix de conception la volonté de Boeing de minimiser la communication sur le MCAS afin de présenter le pilotage des B737 MAX comme quasi identique à celui des 737 NG et de réduire le surcoût de formation pour les compagnies.
Il y a souvent un prix à payer pour ceux qui introduisent de nouvelles technologies dans les avions de ligne. Il faut financer la maturation techno et la première certification, et on n'est pas à l'abri de risques majeurs qui seraient passés au travers des vérifications et essais. Exemple avec la batterie Ion-Lithium du B787. Pour autant, ce dernier a jusque ici eu assez peu d'ennuis de jeunesse par rapport au nombre d'innovations introduites.
[^] # Re: A propos du Boeing 737.
Posté par gerfaut83 (site web personnel) . Évalué à 10.
Je suis assez d'accord avec cette analyse.
Si à la fois Airbus et Boeing ont choisi la re-motorisation à la re-conception complète d'un avion, c'est d'abord parce qu'ils se marquent à la culotte, et ensuite parce que même si des technologies récentes permettent de faire des progrès sur le papier, il n'a pas encore été démontré qu'on savait le faire d'un point de vue industriellement rentable…
Airbus a introduit la plupart de ses nouveautés (du point de vue systèmes notamment) sur l'A380. Ils pouvaient se le permettre à l'époque, car au moment du lancement de l'A3XX c'était moins tendu économiquement, et l'avion devait représenter le savoir-faire d'Airbus pour l'avion du XXIème siècle. Les compagnies (certaines, du moins), était prêtes à payer pour un avion de tous les superlatifs (salon-bar, cabines "Première" avec douches privatives…).
L'A380 a pourtant lutté durant tout son (long) développement et sa (courte) carrière avec un problème de sur-poids. Les premiers modèles livrés étaient tellement loin du poids vendu par les commerciaux et tellement en retard qu'Airbus a dû payer des compensations énormes aux premières compagnies livrées.
Aux alentours de 2010, j'avais entendu par des infos internes qu'Airbus estimait que le nombre d'A380 à vendre pour amortir le développement ne serait jamais atteint (et à l'époque, ils ne projetaient pas d'arrêter la chaîne en 2020…).
Ce ne fut pas un échec complet, car l'A380 a permis à l'A350 de bénéficier d'énormément de développements, réutilisés tels quels, ou presque, là où Boeing a connu bien plus de déboires avec son B787 Dreamliner, qui a été parfois été rebaptisé Nightmareliner.
Sauf que l'A350 et le B787 ont eux aussi connu les difficultés rencontrées par l'A380 : non-respect des objectifs de coût, de masse et de délai. En grande partie à cause de l'introduction des composites (l'A380 en avait déjà un peu), encore une fois sur-vendue du point de vue des économies réalisables par les commerciaux d'Airbus et de Boeing. Dans l'industrie, on peut rarement chiffrer les économies en faisant A - B, surtout lorsque B a une forte influence sur A… Et la structure composite a eu une forte influence sur énormément de choses.
Pareil pour les systèmes : une autre des principales difficultés venait de l'augmentation du nombre de systèmes électrique, qui exigeait un redimensionnement des systèmes de refroidissement, qui à leur tour avaient un impact sur la consommation électrique et le poids…
D'évidence, loger toute ces technologies dans le format d'un A320 ou d'un B737 ne s'annonce pas simple du tout. Et je pense que ça effraye les deux constructeurs. Car se louper sur l'avion qui assure la majeure partie de la trésorerie de l'entreprise représente un risque économique bien plus élevé que de se louper sur des avions qui représentent beaucoup moins de volume (Boeing la démontré avec la crise du 737-Max).
La plupart des analystes annoncent que ces avions verront le jour lorsqu'il y aura une véritable rupture technologique (principalement au niveau moteur) qui justifiera une re-conception complète, en abaissant le coût opérationnel de manière bien plus significative que ce qu'un A320-Neo ou qu'un 737-Max peut proposer aujourd'hui.
Pourquoi ? Parce que le premier concurrent du remplaçant de l'A320 sera … l'A320, un avion optimisé jusque dans ses derniers retranchements depuis 30 ans, re-motorisé de surcroît, qui a fini par atteindre un taux de disponibilité opérationnel extrêmement élevé (idem pour Boeing, avant l'arrivée du Max). Et cet indicateur (surtout depuis l’essor des compagnies à bas-coût) est considéré en priorité par les compagnies, même avant la performance, le prix de vente ou la consommation (un avion rentable est un avion qui vole). Le temps que le remplaçant arrive à rivaliser avec son prédécesseur, lorsqu'on voit les déboires de conception rencontrés depuis les années 2000 par les avionneurs est, à mon avis, ce qui explique pourquoi personne n'a encore dégainé pour proposer le remplaçant de son best-seller.
[^] # Re: A propos du Boeing 737.
Posté par PhRæD . Évalué à 10.
Je pense qu’avec ce mode de pensée, nous allons inéluctablement vers une perte des compétences : qui saura fabriquer un avion « neuf » dans 20 ans ?
Je ne suis pas sûr que ce dont a été capable Tesla dans le domaine automobile en bousculant les acteurs traditionnels qui continueraient sans ça à nous vanter le diesel (car-ça-on-sait-faire-et-c’est-rentable) soit reproductible dans beaucoup de domaines.
Et c’est valable dans l’informatique : chapeau bas à linux, mais y a-t-il une relève ?
Alors on peut se dire que tant que ça marche, pourquoi chercher plus loin ? Je réponds que ça n’est pas en perfectionnant le silex qu’on a inventé la bougie.
Alors qu’on nous rabat les oreilles avec l’innovation, la frilosité n’a jamais été aussi prégnante. La dictature du « ROI » risque de nous mener vers la stagnation intellectuelle.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: A propos du Boeing 737.
Posté par Pierre Jarillon (site web personnel) . Évalué à 9.
Ce problème est justement celui de la centrale EPR. Une perte de compétence sur la fabrication des centrales nucléaires et un management pitoyable. Pendant ce temps, les chinois exploitent leur centrale EPR.
Une activité qui a été un peu préservée est celle de la force de dissuasion nucléaire à laquelle j'ai contribué pendant une trentaine d'années. Elle est maintenue au niveau le plus bas. Juste un tir de temps en temps pour montrer qu'elle est en état de marche. Bien sûr elle ne sert à rien et j'espère qu'elle ne servira jamais. C'est son but ! C'est la dissuasion.
Si on arrêtait de maintenir cette force, elle disparaitrait et en cas de menace, il faudrait une dizaine d'années pour la recréer. Ce serait un temps de réaction inacceptable.
En attendant, depuis 76 ans, nous vivons en paix sur notre territoire (mis à part les islamistes).
[^] # Re: A propos du Boeing 737.
Posté par Funix (site web personnel, Mastodon) . Évalué à 2.
Concernant la dissuasion si on perd les compétences et tous les outils pour les maintenir (côté indus et étatique), à mon avis c'est fichu, c'est bien plus d'une dizaine d'années qu'il faudra et des milliards et des milliards d'euros.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: A propos du Boeing 737.
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Pour les milliards d'euros, je suis d'accord. Pour le délai, une dizaine d'années me semblent suffisantes. Il n'en a pas fallu plus pour obtenir la première génération, le SSBS S2. Voir Missile S2. On avait mis en œuvre à l'époque des moyens considérables. Nous avions des crédits non pas illimités mais presque.
Avec l'informatique on gagne beaucoup de temps. Le plus long, ce sont les essais de validation car il faut mettre en œuvre des moyens conséquents.
Le point le plus délicat est la conservation du savoir-faire et la conservation des études et des plans anciens.
Ce que je regrette dans ce genre d'archives est la trace de ce qui n'a pas fonctionné et pourquoi on l'a rejeté.
[^] # Re: A propos du Boeing 737.
Posté par windu.2b . Évalué à -4.
Preuve que la dissuasion nucléaire ne répond plus aux menaces de notre époque. Sauf à décider un jour de larguer une bombe atomique dans le désert du Mali, "et tant pis pour les villages qui se trouveraient à proximité des camps d'entraînement des djhadistes" ?
[^] # Re: A propos du Boeing 737.
Posté par barmic 🦦 . Évalué à 6.
Preuve qu'elle n'est plus suffisante pas qu'elle n'a plus utile.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à -3.
A-t-elle jamais été suffisante ?
[^] # Re: A propos du Boeing 737.
Posté par Pierre Jarillon (site web personnel) . Évalué à 0.
Ce n'est pas le souci majeur pour l'instant… Des pays comme l'Iran ou la Corée du nord par exemple pourraient devenir des menaces sérieuses. Il vaut mieux être prêts avant qu'il ne soit trop tard.
C'est hors sujet : J'ai bien écrit "sur notre territoire".
[^] # Re: A propos du Boeing 737.
Posté par windu.2b . Évalué à 0.
J'ai bien compris. Mais mon propos faisait référence au fait que les terroristes sont souvent formés dans des camps d'entraînement à l'étranger : on les atomise, ou pas alors ?
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 3.
Peux-tu dire, de façon fiable, quelles seront les menaces importantes dans 10 ans ?
[^] # Re: A propos du Boeing 737.
Posté par groumf . Évalué à 3.
Pour renouer avec le sujet ça me rappelle quand mon boss m'avait demandé de rédiger un PCA (plan de continuité de l'activité). Le PCA devait prendre en compte tous les types de pannes ou de désastres qui pouvait subvenir et la procédure pour les surmonter sans interruption du service. Je lui ai répondu qu'on n'était pas la NASA et que de chercher à imaginer toutes les couilles qui pouvaient survenir allait cannibaliser du temps utile et serai au final au détriment de la fiabilité du service.
[^] # Re: A propos du Boeing 737.
Posté par claudex . Évalué à 5.
Moi j'avais parlé des sauterelles et de la mort des premiers nés mais je n'avais pas trouvé de solution contre ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: A propos du Boeing 737.
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Il y a quand même des problèmes plus ou moins courants (feu, inondation, vol, cryptolocker) dont il serait incompréhensible de ne pas tenir compte.
"La première sécurité est la liberté"
[^] # Re: A propos du Boeing 737.
Posté par groumf . Évalué à 1.
C'était au sein d'une entreprise de moins de vingt salariés. Le PCA était une demande contractuelle faite par nos clients, quoi qu'on ait mis dedans, de toute façon on n'avait pas le budget pour le mettre en oeuvre. Qu'est-ce qu'il aurait fallu faire ? Rédiger un document bidon pour faire plaisir aux clients et se retrouver légalement dans la panade en cas de pépin ou expliquer aux clients que s'ils veulent un prestataire plus résilient ils doivent payer plus pour l'abonnement au service ?
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 3. Dernière modification le 31 août 2020 à 22:47.
Rédiger un PCA ne veut pas dire que tu as une solution instantanée à tous les problèmes.
Il y a plein de cas qu'on peut prévoir (ransomware, inondation, incendie, grèves, …) et on peut parfois trouver des solutions pas chères (même si elles sont imparfaites) mais qui demandent un peu d'anticipation.
[^] # Re: A propos du Boeing 737.
Posté par groumf . Évalué à 4.
C'est toujours ce que tu n'as pas prévu qui te fout dans la merde. Le jour où on a eu un gréviste en flamme qui revendiquait dans la salle serveur les pompiers ont tout aspergé en bloc sans discernement. J'avais bien mis une affiche sur la porte en précisant qu'il ne fallait pas mouiller le serveur de backup, mais ses cons sont passés par la fenêtre.
Plus sérieusement le management a bien vu que je mettais de la mauvaise volonté et ils ont trouvé quelqu'un de plus apte pour cette tâche que moi et m'ont fait bosser sur des trucs qui utilisait mes points forts plutôt que mes points faibles.
[^] # Re: A propos du Boeing 737.
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pour atomiser un camp d'entrainement en plein désert, pas besoin d'une bombe atomique.
"La première sécurité est la liberté"
[^] # Re: A propos du Boeing 737.
Posté par lagou . Évalué à 1.
Éteins ta télé, tu vas trop loin.
[^] # Re: A propos du Boeing 737.
Posté par dj_ (site web personnel) . Évalué à 10.
mis à part les terroristes ;) (pour n'importe quel motif idéologique)
Terrorisme en France
[^] # Re: A propos du Boeing 737.
Posté par 2PetitsVerres . Évalué à 3.
Pas les gens qui savent faire un avion classique je pense. Enfin, il sauront faire un avion équivalent, mais pas un avion "révolutionnaire". Ils essayent, que ce soit Airbus ou Boeing, ils ont de la R&D, ils ont des concepts, ils rachètent des startup, mais j'ai l'impression qu'un jour il pourrait se passer la même chose que le pied au cul de Tesla dans les constructeurs automobiles traditionnels. Tesla ne va pas les faire disparaître, mais il va les obliger (les oblige déjà) à changer certaines méthodes (et pas que sur le plan fossile vs électrique)
Mais la barrière à l'entrée est beaucoup plus haute (et ce n'est pas vraiment Comac qui va mettre ce pied au cul sur le plan technologique. Enfin, je ne crois pas. Ce sera juste un pied au cul sur le prix, mais avec peu d'innovations, mais je peux me tromper)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: A propos du Boeing 737.
Posté par windu.2b . Évalué à 5.
N'étant pas du tout passionné par ce domaine, je passe sans doute à coté de quelque chose, mais je me demande quand même : en quoi Tesla a-t-elle révolutionné le monde de l'automobile ?
(c'est une vraie question)
[^] # Re: A propos du Boeing 737.
Posté par 2PetitsVerres . Évalué à 4.
Révolutionner est peut-être un grand mot, mais il y a pas mal de choses que Tesla fait différemment (Je ne suis pas un passionné non plus, mais il se trouve que certains clients de mon employeur sont des OEM ou des fournisseurs dans l'industrie), du coup pour citer quelque trucs que j'ai retenu (mais ça peut être faux)
Après il y a aussi un peu de bullshit marketing (Comme appeler un système d'aide à la conduite "auto pilot", et dire qu'on va avoir des véhicules autonomes de niveau 4/5 d'ici bientôt, alors qu'en vrai, c'est pas vraiment sûr mais ça aussi ça fait réagir les OEM classiques) Après sur l'autonomous driving et les aides à la conduite, il n'y a pas que Tesla, mais plusieurs acteurs qui ont forcé un peu la main au classique pour aller plus vite (ou pour faire pareil, et eux aussi dire qu'ils auront tout ça bientôt)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: A propos du Boeing 737.
Posté par PhRæD . Évalué à 4.
Tesla a produit de manière industrielle une voiture électrique défiant tout les standards du marché :
* autonomie ;
* équipement ;
* performance ;
* prix.
C’était à tel point que je me rappelle une discussion dans un forum où un porschiste voyait ses arguments battus en brèche un à un (notamment le rapport performance / prix / habitabilité / coût d’usage) déclarait : « mais à quoi bon de telles performances » !
Juste pour donner un ordre d’idée : Youtube fourmille de vidéo présentant des courses départ arrété face à des ultra-sportives coutant jusqu’à 3 fois son prix et les laisser littéralement sur place. Tout ça dans une familiale 7 places et un silence de cathédrale.
Par ailleurs, c’est le premier constructeur qui à ma connaissance propose de continuellement faire bénéficier les véhicules déjà produits des avancées ajoutées aux nouvelles production.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: A propos du Boeing 737.
Posté par rewind (Mastodon) . Évalué à 5.
Tesla a révolutionné l'automobile comme Apple a révolutionné la téléphonie #sarcasme
[^] # Re: A propos du Boeing 737.
Posté par PhRæD . Évalué à 0.
Il faut bien reconnaitre qu’Apple a popularisé l’interface tactile reprise depuis sur tous les ordiphones.
Au passage, l’interface « tablette » de la model S (commercialisée en 2012) est en train d'être reprise par tous les constructeurs (l’inspiration la plus flagrante étant chez Renault).
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: A propos du Boeing 737.
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
C'est le cas, avant l'iphone 1, personne ne savait rendre le web utilisable sur mobile (grace au multitouch). Nokia avait tenté sans succès.
"La première sécurité est la liberté"
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 5.
Comme Apple est reparti de zéro pour concevoir l'interface de l'iPhone, Tesla est parti de zéro pour concevoir le système informatique de sa Tesla.
Du coup, ils ont un système beaucoup mieux intégré, avec manifestement beaucoup d'avance (dixit un grand groupe automobile allemand, mais je ne sais plus lequel).
N'étant pas du domaine, je vais sûrement raconter des bêtises, mais c'est manifestement plus simple à faire évoluer (plutôt que plein de composants conçus comme indépendants).
Ça se voit au niveau de l'interface graphique, apparemment.
[^] # Re: A propos du Boeing 737.
Posté par Anonyme . Évalué à 4. Dernière modification le 01 septembre 2020 à 14:36.
Tu veux dire par exemple comme de provoquer un coup d’état dans un pays d’Amérique-du-Sud pour mettre la main sur les mines de lithium ?
Si c’est ça, j’espère sincèrement qu’on aura pas de Tesla (ni même d’Elon Musk) dans l’aviation.
[^] # Re: A propos du Boeing 737.
Posté par 2PetitsVerres . Évalué à 6.
Je ne suis pas sûr que l'industrie des carburants fossiles soit beaucoup plus propre sur les aspects coup d'états que celle des batteries, en fait.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: A propos du Boeing 737.
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Ni l'industrie du fruit, d'ailleurs.
"La première sécurité est la liberté"
[^] # Re: A propos du Boeing 737.
Posté par 2PetitsVerres . Évalué à 1.
Oui mais les voitures classiques roulent rarement à l'huile de fruit ;-)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: A propos du Boeing 737.
Posté par ZeroHeure . Évalué à 2.
Les conducteurs devraient par contre.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 7.
Les Américains ont déjà le problème pour les avions de combat.
Il y a des erreurs sur le F-35 qui sont simplement inacceptables (feux de position mal placés qui ne sont pas visibles, crosse d'appontage mal placée, refroidissement assuré par la circulation du carburant sans se demander ce qui se passe quand il n'y a plus de carburant, …).
On aura certainement le même problème pour l'après-Rafale, d'ailleurs.
Les Chinois n'ont pas ce problème : ils font moins bien, mais changent tellement souvent de gamme qu'ils montent en compétence.
[^] # Re: A propos du Boeing 737.
Posté par Kerro . Évalué à 6.
Quand il n'y a plus de carburant, il a encore de la chaleur produite ?
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 4.
L’électronique continue de fonctionner jusqu’à la fin de la mission ;)
[^] # Re: A propos du Boeing 737.
Posté par Kerro . Évalué à 5.
Sans carburant, un avion de chasse est détruit dans presque tous les cas s'il n'est pas à proximité immédiate d'une piste (de mémoire le plus long vol documenté d'un avion de chasse moderne sans carburant et sans crash a duré 3 minutes, donc les autres ont duré moins).
À première vue c'est un argument qui ne me semble par pertinent.
C'est peut-être ce qu'on pensé les concepteurs.
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 5. Dernière modification le 30 août 2020 à 20:56.
La quantité de chaleur évacuée par le circuit de carburant devient trop faible avant que l'avion se retrouve complètement à sec. Ce n'est pas complètement binaire…
[^] # Re: A propos du Boeing 737.
Posté par windu.2b . Évalué à 3.
Sauf que ce record ne nous dit pas s'il n'y a pas eu des vols planés plus longs qui auraient pu bien se finir, si d'autres conditions avaient été meilleures ("piste" suffisamment longue plane et proche, conditions météos plus clémentes, …).
Ou alors les avions de chasse ont une finesse dégueulasse ?
[^] # Re: A propos du Boeing 737.
Posté par Jean-Baptiste Faure . Évalué à 3.
J'ai toujours entendu comparer l'aptitude à voler des avions de chasse à celle d'un fer à repasser.
[^] # Re: A propos du Boeing 737.
Posté par Donk . Évalué à 3.
D'après la page Wikipédia que t'indiques, l'Airbus A320 a une finesse de 17 et celle du Concorde est de 7.5 à Mach 2.
[^] # Re: A propos du Boeing 737.
Posté par windu.2b . Évalué à 2.
J'ai bien vu, mais il n'y a rien sur les avions de chasse en général (peut-être parce que ce n'est pas une info sur laquelle les constructeurs communiquent, pour des raisons de secret militaire ?)
[^] # Re: A propos du Boeing 737.
Posté par 2PetitsVerres . Évalué à 5.
Une petite recherche rapide sur internet nous montre que non, la finesse d'un rafale par exemple est meilleure que celle de la (défunte) navette spatiale américaine. (5.9 pour le rafale, à une vitesse non spécifiée, pour une finesse entre 1 (en hypersonique) et 5 (en subsonique) pour la navette spatiale en fonction de sa vitesse. Si on continue la comparaison, un caillou à une finesse inférieure à 1 (pour la plupart des cailloux), donc le rafale est plutôt bon
Par contre, si on compare le rafale à des objets censés voler, plutôt qu'à des objets censés tomber, effectivement, la comparaison est moins glorieuses (normalement on doit avoir quelque chose comme planneur > avion de ligne > avion de tourisme > avion de chasse > navette spatiale)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: A propos du Boeing 737.
Posté par lym . Évalué à 6.
Pour le planeur vs avion de ligne, c'est pas si loin selon le planeur. Si les modèles de compétition sont vers les 60 de finesse, les bois et toile classiques pour l'instruction sont plutôt dans les de 25 à 30. Un avion léger d'aéroclub sera dans les 10/15.
Et puis quand on a un pilote de ligne vélivole à ses heures perdues aux commandes, la finesse d'un avion de ligne (dans les 20) peut vous sauver la vie:
https://fr.wikipedia.org/wiki/Planeur_de_Gimli
[^] # Re: A propos du Boeing 737.
Posté par Tonton Th (Mastodon) . Évalué à 4.
La Caravelle le faisait déja en 1959.
[^] # Re: A propos du Boeing 737.
Posté par Dring . Évalué à 9.
Je me rappelle très bien de la scène dans le film. C'est Legolas qui fait voler Gimli ; par contre niveau portance c'est pas top.
[^] # Re: A propos du Boeing 737.
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
"qui saura fabriquer un avion « neuf » dans 20 ans ?"
Les chinois et les russes pour sur et les indiens peut être.
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 1.
Il y a plus de chances qu’on sache toujours faire des avions dans 20 ans que les Indiens :D
[^] # Re: A propos du Boeing 737.
Posté par windu.2b . Évalué à 3.
Pourquoi les Indiens ne sauraient-ils pas faire des avions dans 20 ans, si l'envie d'avoir leur propre industrie aérienne leur venait ?
Après tout, ils ont bien leur propre industrie spatiale !
[^] # Re: A propos du Boeing 737.
Posté par flan (site web personnel) . Évalué à 4.
Parce que ça fait plus de 60 ans qu'ils en ont déjà l'envie et qu'ils essaient, et que ça avance… lentement.
Il y a 60 ans, ils étaient largement en avance sur la Chine (en étant capable de faire un avion supersonique presque tous seuls), et maintenant ils sont loins derrière.
Le Tejas, qui a fait son premier vol il y a 20 ans, est loin d'être au niveau.
[^] # Re: A propos du Boeing 737.
Posté par Pol' uX (site web personnel) . Évalué à 8.
Mais à quoi cela pourra t'il bien servir ?
Adhérer à l'April, ça vous tente ?
[^] # Re: A propos du Boeing 737.
Posté par gerfaut83 (site web personnel) . Évalué à 6.
Je pense que ce ne sont pas les salariés d'Airbus membre du bureau d'étude, qui ont fait les frais des principaux plans de restructuration/compétitivité/licenciement (rayez les mentions inutiles) de ces 25 dernières années, qui te contrediront…
Il faut aussi prendre en compte que la durée de vie d'un programme avion dépasse de loin celle d'une voiture, par exemple (pour ne pas parler de celle d'un smartphone…).
Un avion prend environ 5 à 10 ans pour sa conception, il est présent au catalogue pendant plus de 30 ans (depuis 1988 pour l'A320, beaucoup plus pour le B737, mais il a tellement changé que ce n'est plus le même avion qu'au début, sauf pour les autorités de certification américaines !!), et ensuite il peut encore voler pendant 25 à 30 ans (soit environ 100 000 cycles de décollage-atterrissage) dans des compagnies à peu près sérieuses (paradoxalement, les compagnies qui ont les flottes les plus jeunes sont les low-cost, car elles les font voler vraiment souvent!). Et on n'évoque pas ici une éventuelle seconde vie dans des pays beaucoup moins à cheval sur les réglementations !
Les premiers ingénieurs en chef de l'A320 sont à la retraite depuis un bon moment (programme lancé officiellement en 1984).
De manière plus générale, la transmission et la conservation du savoir et du savoir-faire en entreprise est un vrai défi.
Après, ça dépend un peu de la culture d'entreprise. Aux États-Unis, la grande mobilité (subie ?) des salariée fait que c'est beaucoup moins choquant de se séparer de tout son bureau d'étude lorsqu'on a rien en prévision. C'est en partie ce qui a permis à l'avionneur brésilien Embraer de débaucher quelques très bons ingénieurs à la fin du programme de développement du B777 pour attaquer le segment des avions monocouloirs de plus de 100 passagers, sur lequel il n'était pas encore présent.
Ça a tellement bien fonctionner qu'en 2018, Boeing s'est lancé dans le rachat d'Embraer pour plus de 4 milliards de dollars (à moins que ce ne soit pour copier Airbus qui venait de reprendre les monocouloirs CSeries du canadien Bombardier), avant de finalement renoncer en 2020, suite à ses déboires financiers (737-Max + Covid-19)…
# Complément sur le Vasa
Posté par Funix (site web personnel, Mastodon) . Évalué à 10.
Pour le Vasa on peut maintenant se féliciter de l'erreur de conception du Vasa, car après être resté des siècles dans la vase, il a été renfloué dans les années 60 et il peut maintenant être observé à Stockholm dans un état de conservation incroyable.
Si vous passez par là bas, je vous conseille la visite ça vaut franchement le coup.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Complément sur le Vasa
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Je confirme. J'ai eu la chance d'aller le voir. Je ne suis pas passionné de bateaux, mais je pense que la visite du Vasa est un moment inoubliable.
Il m'en est resté à la fois un sentiment admiratif devant l'œuvre extraordinaire et une sensation de gâchis.
Les textes qui y sont présentés montrent bien comment la course aux performances conduite par des personnes incompétentes a conduit à la catastrophe. C'est ce qui m'a conduit à écrire un chapitre dans cet article à propos du Vasa.
[^] # Re: Complément sur le Vasa
Posté par 2PetitsVerres . Évalué à 4.
Je vais allez dans le sens de tout le monde, mais je confirme ce que tu dis, si vous êtes à Stockholm et que vous avez un peu de temps, c'est certainement un truc à faire.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Complément sur le Vasa
Posté par jacot . Évalué à 1.
Je dirai même plus, c'est le seul truc à voir à Stockholm ;-)
IlL y plus prêt pour voir un beau bateau, c'est l'Hermione à Rochefort que j'ai visité la semaine dernière et qui est aussi magnifique à visiter.
# Incompétence
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Les catastrophes évoquées dans cet article ont un point commun : l'incompétence des décideurs.
Comment des personnes incompétentes ont-elles pu arriver à un tel niveau décisionnel ? Il y a plusieurs possibilités.
La perte de compétence des dirigeants est quasiment inéluctable dans les grandes et vieilles entreprises. Ceux qui montent dans la hiérarchie sont rarement les plus compétents, ce qui fait qu'ils ont du mal à juger de la compétence de leurs collaborateurs. Comme le problème est récursif, c'est toute l'entreprise qui en pâtit.
[^] # Re: Incompétence
Posté par Funix (site web personnel, Mastodon) . Évalué à 10.
Je rajouterai pour les grandes entreprises et administrations françaises, le corporatisme, le filtre pour accéder aux postes à direction se fait sur ton école d'origine, X, Ponts, mine ou centrale pour simplifier et non pas sur la compétence des individus. On ne peut pas nier leur compétence intrinsèque après avoir réussi de brillantes études, mais le problème est que le système ne les oblige pas à entretenir ces compétences, à prendre des risques et à se remettre en cause, à réapprendre sans cesse car ils ont un boulevard de carrière assuré vers les postes de direction.
En parallèle on retrouve les ingénieurs qui sont sortis de la petite école d'ing, ou pire encore qui sont issues de la voie universitaire qui malgré les compétences qu'ils ont pu développer durant leur carrière, qui vont se heurter à un plafond de verre pour accéder aux postes à direction.
On se retrouve avec des chefs qui évoluent dans des hautes sphères en décalage complet avec la réalité du terrain.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Incompétence
Posté par Pierre Jarillon (site web personnel) . Évalué à 10. Dernière modification le 28 août 2020 à 11:43.
Tout à fait d'accord. Je pense que le cas le plus emblématique est l'ENA.
On m'avait expliqué que lorsque l'on embauchait quelqu'un on lui proposait un profil de carrière. Cette évolution était essentiellement basée sur l'école d'origine.
Dans mon entreprise, il y a eu aussi un autre phénomène, celui des gens issus des Arts et Métiers (ENSAM) qui n'embauchaient que des gens issus de l'ENSAM, nuisant à la diversité de formation et de compétences, source de richesse. Bien sûr, certains d'entre eux étaient brillants, mais ce n'étaient ni les plus nombreux, ni les mieux promus. Il y a des grandes écoles et des grosses écoles.
L'une des plus grosses catastrophes est la formation de nos politiciens. Ce sont en très grande majorité des avocats, des enseignants (surtout littéraires) et une pincée de scientifiques (médecins). Ce qui veut dire que nous sommes gouvernés majoritairement par des personnes qui ne sont pas intellectuellement dans notre siècle. Ce sont les sciences et les techniques qui changent le monde et notre civilisation. Gouverner, c'est prévoir. Prévoir, c'est faire de la prospective et ce n'est possible que si l'on comprend parfaitement les sciences et les techniques pour imaginer où elles peuvent nous conduire. Cela permet alors d'influer sur leur évolution.
C'est de la politique à moyen et long terme. Malheureusement, leur souci est de se faire réélire.
[^] # Re: Incompétence
Posté par barmic 🦦 . Évalué à 4.
C'est un ingénieur sorti des hautes écoles françaises qui est responsable du Vasa ? La NASA est dirigée par des diplômés d'écoles françaises ?
Tu semble chercher avoir un apriori (pas forcément sans fondement) et cherche à y recoller alors qu'il n'y a rien qui permet de le faire. Ce que montre la dépêche c'est que le problème est justement nettement plus large que ça, qu'il le dépasse en espace et en temps. Il est généralement plus intéressant pour corriger un problème de chercher la racine, son essence, plutôt que de s'attaquer à son aspect extérieur.
Ensuite ce n'est pas l'énumération de quelques cas qui peuvent prétendre montrer s'il s’agit d'un problème systémique. À coté de ses cas (non exhaustifs) combien réussissent ? Pourquoi ils réussissent ?
Définir la cause d'un échec est bien complexe, c'est rare qu'une personne sabote un projet. Il y a généralement des séries de problèmes qui mènent à un désastre (ça peut aussi se voir dans la réalisation d'un film d'ailleurs, même si juger de la qualité d'une œuvre est plus subjective).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Incompétence
Posté par Funix (site web personnel, Mastodon) . Évalué à 3.
cf. l'introduction de mon message, je n'avais pas la prétention de donner une raison universelle à ces ratés mais c'est juste un élément supplémentaire à l'énumération de Pierre pour le cas particulier des grandes entreprises et administrations françaises.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Incompétence
Posté par abriotde (site web personnel, Mastodon) . Évalué à 10.
Je pense que dans toute entreprise, on ne devrait que très rarement embaucher à un poste de haut niveau car c'est alors beaucoup plus facile de se tromper que de valoriser une personne d'un niveau en dessous pour ses compétences. Il est très courant qu'un employé tire au flanc ou pas dans son domaine de compétence cherche à flouer une entreprise en se faisant embaucher à un poste de management.
D'ailleurs il y a une très bonne pratique (qui a plutôt tendance à se perdre) qui consistait pour les cadres, a les obliger à passer 6 mois par le stade ouvrier (payé au salaire de cadre). Outre la formation que cela donne, cela évite les embauche d’opportunité (ceux qui vienne pour rester 2 ans et partir pour monter ailleurs), cela rapproche les cadres des ouvriers…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Incompétence
Posté par barmic 🦦 . Évalué à 8.
La logique c'est de prendre quelqu'un qui est bon à son poste et à l'en changer ? C'est le principe de Peter ça :)
Je connais une boite où tous les employés doivent passer une semaine par an sur le poste le plus bas de l'échelle. Ça n'empêche pas toute la hiérarchie de ne faire aucune confiance en vers leurs employés.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Incompétence
Posté par Gabbro . Évalué à 7.
Cette phrase m'étonne un peu, parce que je ne vois pas en quoi c'est un problème (pour la boite, si, mais de manière générale). Je suis sur le marché du travail depuis moins de 5 ans, et je vais être embauché dans ma 3e boite, pour faire la même chose que ce que je faisais jusqu'ici, en étant mieux payé (débauchage). Mais j'avais pas mal changé de direction entre mon premier et mon deuxième poste.
D'ici quelques années, je vais me lasser du domaine, et je cherchais autre chose. Si ma boite ne peux pas me le fournir, j'irai voir ailleurs sans aucune hésitation. Et si je tombe avant sur une bonne opportunité, je la saisirai.
Je ne suis pas fidèle à ma boite, de même que les boites se sentent rarement obligés devant leur employés (il suffit de voir les plans sociaux). Donc saisir les opportunités me semble totalement normal.
[^] # Re: Incompétence
Posté par izulium . Évalué à 4.
Je trouve cette discussion intéressante. La formation initiale semble très importante dans plusieurs pays notamment en France et ceci, à mon sens, pour de multiples raisons: Relations de l'époque, réseau d'anciens de l'école, connaissance du contenu de la formation…
Théoriquement, un décideur doit savoir s'entourer… et c'est souvent là le problème. Pour avoir confiance, il risque de privilégier des profils similaires au sien. Des profils qu'il comprend et avec qui il a des affinités (Combien de temps passons-nous au travail?).
J'ajouterai que dans un monde où on évite les vagues, les profils différents, à fort caractère ou ayant la critique facile sont souvent écartés, réprimandés ou mis au silence.
# Mon avis (insignifiant)
Posté par 2PetitsVerres . Évalué à 5.
J'ai un avis personnel sur la classification "Ariane 501 : Software ou système ?" si je peux appeler ça comme ça. Et je pense qu'une partie peut s'appliquer au cas Boeing.
Si il y a des erreurs logicielles indéniables (pourquoi certaines conversions sont protégées et d'autre non par exemple), pour moi la cause élémentaire est système. C'est le système qui décide de réutiliser des parties, c'est le système qui décide de se passer de certains tests. Normalement, c'est aussi l'analyse système qui doit décider des exigences systèmes qui sont affinées en exigences logicielles, et la revue d'exigences en passant d'une version d'un produit à un autre aurait dû voir ce problème.
Ça ne veut pas dire que les ingénieurs logiciels n'auraient rien dû voir, ou rien dû dire, s'ils en ont eu l'opportunité (le problème, c'est que si je comprends bien l'histoire, le logiciel de l'ordinateur de bord a été changé, mais pas vraiment celui des centrales inertielles, donc c'est à l'interface entre deux logiciels que le problème a lieu, difficile à voir si ce sont des équipes indépendantes. Encore une fois, c'est de l'intégration système.) Mais de façon générale, si un développeur (ou une équipe, ou un intégrateur) voit un problème potentiel, il doit être remonté. La DO-178C/ED-12C (pas applicable pour Ariane 5, déjà elle n'existait pas en 1996, et c'est plutôt un truc d'aéronautique que d'aérospatial) dit par exemple :
C'est le process système qui est responsable de ce niveau là, mais il est de la responsabilité des autres équipes (par exemple logicielles) de faire savoir qu'un problème potentiel peut avoir lieu. Si votre rôle c'est de faire le logiciel, et que l'exigence dit un truc absurde, ou vague, ou étrange, ou qui semble anormal, il faut remonter l'information.
(Et c'est là que si j'ai bien compris, mais à prendre avec précaution, dans l'histoire de l'avion, une partie du logiciel est externalisée, et faite par des gens qui font du logiciel, mais qui n'ont peut-être pas une compréhension du système, et qu'ils ont peut-être moins de poids quand ils remontent ce genre d'information. Le logiciel ne devrait pas juste être là pour implémenter les exigences, il doit/devrait pouvoir les critiquer)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Mon avis (insignifiant)
Posté par Nagoydede . Évalué à 5.
Ça résume bien la théorie de la pratique.
Le mot d'ordre devrait être communication.
Or, dans les faits, c'est plus compliqué.
Pour une modification de ce type, le "codeur" va certainement envoyé une facture pour l'implémentation de la nouvelle spécification, etc… D'autant plus que ce n'est pas lui qui est à la source du problème.
Du coup, il y a toujours la guéguerre classique (extrait d'échanges de mails plus ou moins vrais"
"(Donneur d'ordres) non la spec est claire..,
- Non ça l'est pas, moi j'implemente pas
- de toute façon c'est moi qui paye et qui ait la responsabilité, ton avis au final…".
Ou l'autre version :
"La safety nous dit que le design actuel que vous fournissez ne peut pas être accepté en l'état.
- oui, mais vous achetez un COTS, c'est comme ça et le produit est déjà certifié, on ne change rien ou alors vous payez toutes les modifications !?
- vous nous avez déjà fait le coup avec la mod xxx, qui n'est toujours pas correctement implémenter et vous nous obligez a avoir encore une nouvelle version…??! On ne paye pas.
- c'est votre définition, nous on change rien a ce qui a été défini il y a (5/10/15…)ans ou on se retire du contrat.
Voilà, on est plus proche d'une situation réelle. Elle va surtout ce produire lorsque le sous traitant est borné, très orienté contrat commercial, en position de force technique et financière et que les systèmes critiques sont très sous traités.
Certains font le développement des parties critiques (commandes de vol, software et hardware) en interne, justement pour éviter ce genre d'embrouilles. Elles en ont tout de même car les services ont des budgets différents, mais une personne très haut placé peut toujours forcer une application. Et la communication est plus simple également.
Beaucoup pensent que prendre un COTS est moins cher. Je pense surtout l'effet inverse… C'est payer cher un produit qui ne peut pas implémenter totalement (ou mal implémenter) les besoins. Au final, le fournisseur s'en sort toujours bien, tant d'un point de vue réglementaires/juridiques que financièrement (je vous laisse regarder les chiffres d'affaires des principaux systèmes vs ceux des constructeurs).
[^] # Re: Mon avis (insignifiant)
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Un COTS peut couter 10 fois moins chère qu'un développement sur mesure. C'est son intérêt. Et évidement que le modifier coute une fortune, le moindre ligne de code changée nécessite de revalider l'ensemble. Et évidement, que cela peut couter plus chère que le prix complet négocié pour un appareil.
"La première sécurité est la liberté"
[^] # Re: Mon avis (insignifiant)
Posté par jb07 . Évalué à 4.
La DO-178 existait du temps d'Ariane V. La centrale Quasar 3000 (qui a volé sur Ariane pour la première fois en 2001 ou 2002, je ne me souviens plus bien) a par exemple été réalisée en conformité avec la DO-178*B* level A.
Il faut savoir que les équipes sont très segmentées : la spec du lanceur est faite par Ariane Espace, la case à équipement, il me semble que c'était Matra Espace, et le SRI c'était Thales Avionics, ça j'en suis sûr et certain. L'équipe système du SRI était à Châtellerault, et l'équipe logiciel à Valence. Donc entre celui qui a connaissance de l'évolution du biais horizontal entre Ariane IV et Ariane V, la distance et l'absence de communication sont telles que l'équipe logiciel n'a aucune chance de le savoir. On leur dit : on conserve la fonction d'alignement telle quelle, ils le font.
Pour en revenir à l'article, j'ai été surpris par une énorme confusion entre le boîtier (le SRI - Système de Référence Inertielle) et sa fonction d'alignement. Le SRI ne s'arrête pas au bout de 40s, c'est la fonction d'alignement qui s'arrête - elle fonctionne assez longtemps pour permettre un arrêt et une reprise de la séquence de lancement, utile sur Ariane IV, superflue sur Ariane V, une fois les propulseurs à poudre mis à feu, elle décolle et alea jacta est.
Ah un autre point : il n'y a pas de vote de l'OBC (On Board Computer) entre les données fournies par les SRI. D'abord pour voter, il faut un nombre impair de sources. Il y a un SRI qui fournit les données, et une fois en panne, on bascule sur le second SRI.
Sur Quasar 3000, un système de récupération avait été mis en place pour que le SRI "retombe sur ses pattes" en cas d'exception logicielle. Pas question de voir le même problème se reproduire…
J'ignore si la Quasar 3000 est encore utilisée aujourd'hui. Elle était magnifique avec son gyrolaser tri-axes ;-)
[^] # Re: Mon avis (insignifiant)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Tu es sûr de ça ? je n'ai jamais vu un équipement spatial suivre la DO.
On m'avait dit qu'il y avait un modèle mathématique interne dans l'OBC servait de 3ième capteur.
"La première sécurité est la liberté"
[^] # Re: Mon avis (insignifiant)
Posté par jb07 . Évalué à 1.
Pour la DO, sûr et certain, même si certains puristes disent que ce n'était pas la vraie DO. Pour le modèle mathématique dans l'OBC, jamais entendu parler, mais je ne connais pas plus que ça l'OBC.
Je pense qu'il contient sans doute des fonctions de vérification de la cohérence des données reçues (le SRI lui-même contient une petite armée de fonctions de vérification de la cohérence de ses données internes, au point que ça consomme une part non négligeable du temps CPU).
[^] # Re: Mon avis (insignifiant)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Est ce qu il y avait un organisme certifieur pour le code avec audit et autre ?
"La première sécurité est la liberté"
[^] # Re: Mon avis (insignifiant)
Posté par jb07 . Évalué à 0.
Non, il me semble qu'il y a eu un audit par des représentants des clients (Arianespace, et l'industriel en charge de la case à équipements).
[^] # Re: Mon avis (insignifiant)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Alors ce n'est pas du tout de la DO. Dans un tel cadre, jamais l'industriel aurait accepter de perdre 6 mois ou 1 an pour un problème avec la norme. Alors que c'est commun en aéronautique : certains ont même dû jeter leur soft et recommencer (FADEC).
"La première sécurité est la liberté"
[^] # Re: Mon avis (insignifiant)
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Je confirme, c'est bien ce que j'ai entendu à l'époque. Les propulseurs à propergols solides ne pouvent pas être arrêtés, le maintien de l'alignement en cas de reprise est inutile et s'est avéré catastrophique.
C'est un problème d'interface entre équipes de développement. C'est au chef de projet qu'il revient de gérer les interfaces. C'est ce manque de gestion qui a conduit à l'échec de la fusée Europa et à son abandon.
# Méthode Larrache
Posté par Benjamin Henrion (site web personnel) . Évalué à 7.
Quand ton concurrent te vole ton marché avec des avions qui consomment moins, les preneurs de décisions demandent "on ne peut pas faire un nouvel avion pour hier?". Développement à l'arrache et "Go go go" font le reste:
https://archive.is/4DoXM
Tiens cela me rappelle quelques développements en mode "Go go go".
# Errare humanum est, perseverare diabolicum
Posté par Big Pete . Évalué à 10. Dernière modification le 28 août 2020 à 19:14.
Quelles que soit les raisons pour lesquelles les hommes font de la merde, ce qui est sur, c'est qu'il sont absolument incapable d'apprendre de leur erreurs.
Deep Water Horizon dix ans aprés en résumé
Le rapport à l'origine de l'info
Quelques perspectives sur la prochaine catastrophe
ça devrait rassurer ceux qui pense qu'on pourrait manquer de pétrole, visiblement, y en a encore plein en arctique, jusqu’à présent on y allait pas parce qu'on sait pas nettoyer en cas de catastrophe (faut croire qu'on sait pas vraiment non plus nous y prendre quand ça se passe dans le golfe du Mexique, mais bon …)
Le plus dingue dans l'histoire, c'est que le pétrole de l’arctique devient "exploitable" a cause du réchauffement climatique. C'est qu'on appelle une boucle de rétroaction positive. Enfin, positive, c'est relatif a l'effet de la boucle sur le système dont elle amplifie la dynamique, hein, mais c'est à peu prés tous ce qu'elle a de positif.
Désolé, c'est un poil HS, à la base je voulais juste évoquer la catastrophe de Deepwater Horizon dans le cadre du sujet évoqué, mais j'ai eu le malheur de tirer un peu le fil …
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Errare humanum est, perseverare diabolicum
Posté par Funix (site web personnel, Mastodon) . Évalué à 1.
Là aussi je conseille le visionnage du film Deepwater, à la fois un bon divertissement dans le genre film catastrophe, on a peine à croire que c'est tiré d'une histoire réelle !
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Errare humanum est, perseverare diabolicum
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
L'histoire réelle est racontée sur Deepwater Horizon. C'est un bon résumé.
[^] # Re: Errare humanum est, perseverare diabolicum
Posté par palm123 (site web personnel) . Évalué à 8.
En plus de ce qui précède, il y a eu un problème entre les anglais et les américains de BP, qui ont compris de manière opposée la phrase du PDG
"we do not like surprises"
Je veux être au courant des problèmes
Ou
Planquez tout sous le tapis
http://gestion-des-risques-interculturels.com/risques/communication-indirecte-et-securite-le-cas-de-bp/
ウィズコロナ
[^] # Re: Errare humanum est, perseverare diabolicum
Posté par Big Pete . Évalué à 9.
Trés intéressant ! Sinon, dans l'article, il y a des liens cassé vers le rapport d'enquête sur la catastrophe a destination de la maison blanche, ce rapport est bien dispo sur le net :
http://www.iadc.org/archived-2014-osc-report/documents/DEEPWATER_ReporttothePresident_FINAL.pdf
C'est assez long, j'ai survolé certaine partie, la première raconte dans le détail l’événement d'une façon assez "littéraire" pour un rapport de ce genre, c'est assez étonnant je trouve, mais du coup, ça rend cette partie moins indigeste.
Une des conclusions du rapport est d’ailleurs tout à fait dans le thème du journal :
Sinon, en résumé, les conclusion du rapport traduite :
À la suite de notre enquête, nous concluons:
• La perte explosive du puits Macondo aurait pu être évitée.
• Les causes immédiates de l'éruption du puits de Macondo peuvent être attribuées à une série d'erreurs identifiables commises par BP, Halliburton et Transocean qui révèlent de telles défaillances systématiques dans la gestion des risques qu'elles mettent en doute la culture de sécurité de l'ensemble de l'industrie.
• L'exploration et la production d'énergie en eau profonde, en particulier aux frontières de l'expérience, comportent des risques pour lesquels ni l'industrie ni le gouvernement ne sont convenablement préparés, mais auxquels ils peuvent et doivent être préparés à l'avenir.
• Pour assurer la sécurité humaine et la protection de l'environnement, la surveillance réglementaire de la location, de l'exploration énergétique et de la production nécessite des réformes allant même au-delà des réformes importantes déjà engagées depuis la catastrophe de Deepwater Horizon. Une réforme fondamentale sera nécessaire à la fois dans la structure des responsables de la surveillance réglementaire et dans leur processus décisionnel interne pour garantir leur autonomie politique, leur expertise technique et leur pleine prise en compte des problèmes de protection de l'environnement.
• Étant donné que la surveillance réglementaire à elle seule ne sera pas suffisante pour assurer une sécurité adéquate, l'industrie pétrolière et gazière devra prendre ses propres mesures unilatérales pour accroître considérablement la sécurité dans l'ensemble de l'industrie, y compris des mécanismes d'auto-contrôle qui complètent l'application gouvernementale.
• La technologie, les lois, les réglementations et les pratiques de confinement, d'intervention et de nettoyage des déversements sont en retard par rapport aux risques réels associés au forage en eau profonde dans de grands réservoirs à haute pression de pétrole et de gaz situés loin au large et à des milliers de pieds sous l'océan. surface. Le gouvernement doit combler l'écart existant et l'industrie doit soutenir plutôt que résister à cet effort.
• La compréhension scientifique des conditions environnementales dans les environnements sensibles des eaux profondes du golfe, le long des habitats côtiers de la région et dans les zones proposées pour davantage de forage, comme l’Arctique, est insuffisante. Il en va de même pour les impacts humains et naturels des déversements d'hydrocarbures.
C'est traduit a coup de google, mais ça me semble ok. A mettre en rapport avec le lien que j'ai donné plus haut sur le bilan 10 après, il semble qu'on soit loin du compte.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Errare humanum est, perseverare diabolicum
Posté par windu.2b . Évalué à 3.
À chaque fois que je lis/j'entends parler de Deep Water Horizon, je me souviens que c'est sur ce sujet que commence la série "The Newsroom", et ça me donne envie de la revoir !
(voilà, c'était mon commentaire pas si utile que ça, sauf s'il a éveillé votre curiosité à propos de cette série que je recommande, vu qu'elle est du même auteur que "The West Wing")
[^] # Re: Errare humanum est, perseverare diabolicum
Posté par FantastIX . Évalué à 2.
Surtout lorsqu'ils sont payés [pour ne pas le faire].
# La folle marche de l'histoire
Posté par solsTiCe (site web personnel) . Évalué à 2.
Dans le même genre, je conseille le livre "La folle marche de l'histoire" B. Tuchman.
Et quand c'est un dirigeant qui envoie son pays dans le mur ?
# Anecdotes Linky
Posté par AnthonyRabine (site web personnel) . Évalué à 10.
Place ici ton expérience dans ce projet titanesque du compteur communicant.
La mienne : travaillant sur le firmware d'un autre compteur utilisant des composants identiques, je trouve un bug dans un driver. Correction faite, j'en informe l'équipe Linky. Réponse : bah on n'a jamais vu le bug chez nous donc on ne corrige pas.
Six mois plus tard réunion de crise car le client Enedis commence à voir des compteurs ne fonctionnant pas super bien …
# Le Guide de terrain pour comprendre l’erreur humaine
Posté par Anonyme . Évalué à 5.
Si je savais structurer mes idées et que j’avais l’assurance de pouvoir l’expliquer sans le paraphraser j’écrirai bien un article sur ce livre.
En tout cas, je le conseil vraiment à tout le monde et je conseille au passage la conférence Who Destroyed Three Mile Island? de Nickolas Means qui introduit la culture « blameless » (et ce livre) en racontant l’histoire de l’accident nucléaire de Three Mile Island.
[^] # Re: Le Guide de terrain pour comprendre l’erreur humaine
Posté par Anonyme . Évalué à 4.
Par contre, je viens seulement de me rendre compte de ça : est-ce qu'un modérateur pourrait corriger la traduction du titre du livre pour ajouter des guillemets autour « d'erreur humaine » ?
Tout l'argument du livre étant que le concept « d'erreur humaine » est une solution facile qui va masquer des causes systémique lors de l'analyse d'un incident. L'auteur considère qu'il faut changer notre vocabulaire pour ne plus utiliser les notions qui renvoie à « l'erreur humaine », c'est pour ça qu'il utilise les guillemets dans le titre du livre.
[^] # Re: Le Guide de terrain pour comprendre l’erreur humaine
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# ariane 5
Posté par Old Geek . Évalué à 1.
Amusant, j'ai croisé quelqu'un il y a quelque mois, qui aurait travaillé sur le projet Ariane 5,
et l'explication du problème est très différente.
Il m'expliquait qu'il s'agissait d'un soucis de fréquence de microcontrôleur inadaptée à la montée de version, et donc de code ne n'exécutant plus avec le bon timing.
[^] # Re: ariane 5
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Ayant vécu le crash d'Ariane 501 d'assez près, je pense qu'il s'agit d'une mauvaise compréhension due à des transmissions successives de bouche à oreille. c'est La déperdition du message.
Ce phénomène permet de faire un jeu de société souvent très divertissant connu sous le nom de jeu de la rumeur.
[^] # Re: ariane 5
Posté par fearan . Évalué à 5.
Pour les plus vieux qui ne suivraient pas la succession de mode du politiquement correct, c'est le téléphone arabe.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: ariane 5
Posté par Pierre Jarillon (site web personnel) . Évalué à 3. Dernière modification le 24 septembre 2020 à 18:54.
… c'est le téléphone arabe.
C'est un téléphone qui est pas mal buggé !
[^] # Re: ariane 5
Posté par jb07 . Évalué à 0.
Vu le décalage avec la réalité, je pense plutôt à un mythomane.
[^] # Re: ariane 5
Posté par Anonyme . Évalué à 3. Dernière modification le 25 septembre 2020 à 07:59.
j'ai fait une formation avec thales, visiblement c'etait eux qui fournissais l'appareil, et l'histoire lu dans le journal, correspond bien a ce que j'ai entendu du formateur.
et il y en avait 3 des centrales dans ariane V, qui se sont arreté l'une après l'autre, la fusée n'a pas explosé a cause des centrales qui bug mais le superviseur qui voyait la fusée partir en vrille a appuyé sur le bouton rouge pour la détruire.
faut être sur de soit dans ce moment :)
[^] # Re: ariane 5
Posté par jb07 . Évalué à 3.
Il n'y a que deux centrales, c'est une simple redondance matérielle. Quand à l'explosion de la fusée, aucun opérateur n'a appuyé sur le bouton (même si c'est possible techniquement). La pression aérodynamique sur le lanceur a arraché les deux boosters, et voyant celà, l'On Board Computer a déclenché l'explosion (c'est dans le rapport d'enquête).
[^] # Re: ariane 5
Posté par Anonyme . Évalué à 4.
comme quoi même proche de la source, l'histoire se déforme un petit peu :)
# Autre exemple...
Posté par lym . Évalué à 5.
Quand on voit qu'un A400M tout frais sorti de l'assemblage a été perdu (tuant l'équipage d'essai) car le FADEC (contrôle moteur), si des calibrations hélice manquaient, était capable d'accepter la puissance maximale au décollage mais qu'ensuite chaque réduction ne permettrait pas de remettre plus de puissance ultérieurement, on ne peut pas trop moquer Boeing hélas.
Et là, on n'a pas l'excuse de pousser à bout un design des années 60 pour économiser sur les requis d'issues de secours actuels, entre autres…
Le pire, c'est que c'était spécifié ainsi! Quel est l'âne qui a pu faire cela? Là ou cela se situe, il doit se faire tout petit outre rhin…
# Therac-25
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Vu sur https://twitter.com/Daviplane/status/1300407146237091842
« Davipla[n]e: Les choix qui ont mené aux incidents des Therac-25 ne sont-ils pas du même ordre, d'ailleurs ?
https://fr.wikipedia.org/wiki/Therac-25 »
Et la page wikipedia évoque « Plusieurs problèmes de gestion du projet informatique » et « D'autres problèmes, liés à la conception et la technique ».
[^] # Re: Therac-25
Posté par Funix (site web personnel, Mastodon) . Évalué à 6.
Dans le même genre on peut rajouter louvois également (même s'il n'y a pas eu mort d'homme)
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Therac-25
Posté par Pierre Jarillon (site web personnel) . Évalué à 9. Dernière modification le 01 septembre 2020 à 21:47.
Dans le même genre, il y a eu Socrate (SNCF) qui a été fait lui aussi en achetant un logiciel à usage aéronautique aux USA pour l'adapter.
Il en est résulté comme pour Louvois un échec monstrueux.
Les raisons de ces échecs sont semblables:
# Dans la série gestion humaine...
Posté par kadreg . Évalué à 10.
Le cas du Herald of Free Enterprise, ferry parti du port de zebbruge, et assez significatif :
https://fr.wikipedia.org/wiki/Herald_of_Free_Enterprise#Erreurs_humaines
Ou comment un ferry appareille portes grandes ouvertes, avec une ligne de flottaison pas d'équerre….
# 2018?...
Posté par FantastIX . Évalué à 4.
… Meltdown et Spectre, qui continuent d'avoir des répercussions aujourd'hui (aka choisir entre performance et sécurité, GKH, 2019)
# Commentaire supprimé
Posté par jalog . Évalué à 0. Dernière modification le 23 septembre 2020 à 10:50.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par jalog . Évalué à 0. Dernière modification le 23 septembre 2020 à 10:50.
Ce commentaire a été supprimé par l’équipe de modération.
# Nextcloud
Posté par cluxter . Évalué à 5.
Nextcloud qui semble royalement ignorer un bug critique depuis plus de 2 ans (le client de synchronisation supprime aléatoirement des répertoires entiers côté client et personne ne comprend pourquoi), malgré les cris d'orfraie de certains utilisateurs (dont moi-même) depuis tout ce temps pour les avertir que c'est une raison qui pousse les utilisateurs vers d'autres solutions : https://github.com/nextcloud/desktop/issues/260
Lorsque j'ai demandé à rouvrir un ticket lié à
ce bugce problème de conception il y a 2 ans pour travailler dessus, on m'a ignoré, puis demandé de m'assurer que mon client était à jour, puis ignoré.Pour ma part, je suis allé tester d'autres solutions et j'ai rapidement jeté mon dévolu sur Seafile qui a changé ma vie. Ca fait moins de choses que Nextcloud, mais ça le fait parfaitement, avec une approche par commits à la git/à la CouchDB, ce qui fait qu'on garde toutes les versions d'un fichier (+ la corbeille pendant X jours si on supprime).
Mais le pire, ce n'est pas tant ce problème de conception affreux qui a posé problème, c'est la façon dont l'équipe officielle (et notamment le co-fondateur) réagit à ce problème. Ils semblent considérer ça comme un bug parmi d'autres, plutôt bénin, absolument pas prioritaire, et rien de sérieux n'a été entrepris dessus. Du coup je me dis que s'ils gèrent leurs équipes de la même façon que leurs utilisateurs, c'est peut être pas étonnant qu'on en arrive à de tels problèmes de conception.
Nextcloud m'a perdu au profit de Seafile et une chose est certaine : je ne reviendrai pas en arrière, pas tant à cause du bug en tant que tel qui rendait leur solution inutilisable dans mon cas, mais surtout à cause de la façon qu'ils ont eu de (ne pas) gérer le problème. S'ils avaient dit "OK c'est vrai que c'est critique, on va bosser dessus en priorité", j'aurais non seulement attendu patiemment d'avoir le patch même s'il avait fallut attendre longtemps, mais j'aurais aussi aidé à débugguer tout le truc. Leur réaction m'a poussé à aller voir ailleurs et pour de bon. Comme quoi les "soft skills", ça compte (aussi) beaucoup, notamment dans la gestion de projet (et dans la communication, ça va sans dire).
[^] # Re: Nextcloud
Posté par Anonyme . Évalué à 2.
perso j'utilise le client owncloud pour mon nextcloud, pour le moment je serre les fesses mais je vais jeter un oeuil a seafile
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.