34 points par GN⁺ 2026-01-01 | Aucun commentaire pour le moment. | Partager sur WhatsApp
  • Diapositive récapitulant 40 principes pratiques applicables à la conception de vaisseaux spatiaux et aux projets d’ingénierie
  • Met en avant comme principes clés l’analyse fondée sur les chiffres, la conception itérative et la conception tolérante aux pannes
  • Inclut un avertissement réaliste : un planning ne va que dans un sens, et les estimations initiales sont toujours sous-évaluées
  • Peut être appliqué tel quel bien au-delà de l’ingénierie spatiale, notamment aux logiciels, aux systèmes et à la conception de startups
  • Checklist réaliste pour éviter les erreurs récurrentes dans le jugement d’ingénierie

Loi 1 — L’ingénierie se démontre par les chiffres

  • "Engineering is done with numbers. Analysis without numbers is only an opinion."
    • L’ingénierie se fait avec des chiffres ; une analyse sans chiffres n’est qu’une opinion
  • Pourquoi les ingénieurs passent autant de temps à apprendre les mathématiques
  • La réussite en ingénierie doit être quantifiable
    • "Mon système est plus rapide" → de combien est-il plus rapide ?
    • "Mon système est moins cher" → quel en est le coût ?
    • "Mon système est plus simple" → comment mesure-t-on cette simplicité ?

Loi 2 — Conception tolérante aux pannes

  • "To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."
    • Concevoir correctement un vaisseau spatial demande un effort infini ; il faut donc le concevoir pour qu’il fonctionne même lorsque certaines choses tournent mal
  • Interdiction de concevoir des systèmes exigeant une fiabilité de 100 %
  • Exemples d’échec : Deep Water Horizon, Fukushima
  • Exemple de vérification logique triple (3 way logic checking) dans les systèmes de contrôle aéronautiques

Loi 3 — Le processus de conception est itératif

  • "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
    • La conception est un processus itératif, et le nombre d’itérations nécessaires est toujours supérieur d’une unité à celui déjà effectué
  • Une bonne conception n’est jamais vraiment terminée

Loi 4 — Faire face à la déception

  • "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
    • Vos meilleurs efforts de conception peuvent inévitablement devenir inutiles dans la conception finale ; il faut apprendre à vivre avec cette déception
  • Loi de Bhargava : seul 1 projet de recherche sur 10 est appliqué dans la pratique industrielle
  • Les plus grands succès commerciaux ne correspondent pas forcément à la meilleure conception technique
    • Exemple : Nokia N95 vs iPhone de 1re génération

Loi 5 (loi de Miller) — Trois points déterminent une courbe

  • "Three points determine a curve."
    • Trois points déterminent une courbe
  • Dans un jeu de données, on finit toujours par trouver un motif
  • Il faut vérifier si ce motif provient réellement du phénomène étudié et non du bruit de mesure
  • Le monde académique et les doctorants ont particulièrement tendance à ignorer cette règle

Loi 6 (loi de Mar) — Se méfier du surajustement des données

  • "Everything is linear if plotted log-log with a fat magic marker."
    • Sur un graphique log-log tracé au gros marqueur, tout paraît linéaire
  • Loi de Bigg : "Ne tombez pas amoureux d’un outil mathématique, il ne vous aimera pas en retour"
  • Interdiction du surajustement (over-fit) des données

Loi 7 — Leadership et composition d’équipe

  • "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
    • Au début d’un projet de conception, la personne qui veut le plus devenir chef d’équipe est souvent la moins susceptible d’en avoir les capacités
  • La BD Dilbert repose sur une version légèrement exagérée de l’expérience réelle dans les entreprises d’ingénierie
  • Une partie du leadership est innée, mais une grande part doit s’apprendre
  • Il existe des managers incapables de respecter les fondamentaux (respect the basics)
    • Demandez à un ingénieur industriel ce qu’il pense d’un MBA

Loi 8 — L’optimum se trouve au milieu

  • "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
    • Dans la nature, l’optimum se trouve presque toujours quelque part au milieu ; il faut se méfier des affirmations selon lesquelles il se situerait à un point extrême
  • Exemple classique : transfert de puissance optimal (Optimal power transfer)
  • Exemple pratique : résistance optimale d’un capteur (optimal sensor resistance)

Loi 9 — Le manque d’information n’est pas une excuse

  • "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
    • Ne pas avoir toutes les informations nécessaires n’est jamais une excuse valable pour ne pas commencer l’analyse
  • Il faut identifier quelles valeurs sont nécessaires pour mener une analyse plus complète

Loi 10 — Estimation et supposition

  • "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
    • En cas de doute, estimez. En cas d’urgence, supposez. Mais revenez impérativement remettre de l’ordre lorsque les vrais chiffres arrivent
  • On est formé comme ingénieur, pas comme voyant
  • Dans ce métier, la qualité de la réflexion compte davantage que la rapidité de pensée

Loi 11 — Repartir de zéro

  • "Sometimes, the fastest way to get to the end is to throw everything out and start over."
    • Parfois, le moyen le plus rapide d’arriver au bout consiste à tout jeter et à recommencer depuis le début
  • Apprendre quand il faut faire cela prend du temps
  • Dans de nombreux secteurs, il y a beaucoup de cas où il aurait fallu le faire, mais où cela n’a pas été fait
    • Station spatiale soviétique de reconnaissance habitée Almaz : conception technique remarquable, mais devenue obsolète après son lancement face aux satellites de reconnaissance pilotés par ordinateur
    • Les premières « automobiles »

Loi 12 — Il n’existe pas de réponse unique

  • "There is never a single right solution. There are always multiple wrong ones, though."
    • Il n’existe jamais une seule bonne solution ; en revanche, il existe toujours plusieurs mauvaises
  • Garder l’esprit ouvert
  • L’ingénierie n’est pas une religion
    • L’apostasie technique (Technical apostasy) est tout à fait permise
  • Exemple : le calcul automatique mécanique
    • Approche dominante pendant la Seconde Guerre mondiale
    • Il a fallu attendre les années 1960 pour que le matériel numérique domine ce domaine

Loi 13 — Concevoir à partir des exigences

  • "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
    • La conception repose sur les exigences ; il n’y a aucune justification à concevoir quelque chose d’un iota « meilleur » que ce qu’elles imposent
  • Les clients détestent payer pour des fonctions dont ils n’ont pas besoin
  • Il faut déterminer le niveau de fiabilité nécessaire à l’application et concevoir en fonction de ce niveau
    • Facile à dire, difficile à exécuter

Loi 14 (loi d’Edison) — Le « mieux » est l’ennemi du « bien »

  • « Better is the enemy of good. »
    • Le « mieux » est l’ennemi du « bien »
  • Il s’agit en réalité d’une citation de Voltaire
  • Il faut savoir reconnaître quand un système a atteint un état suffisamment bon (good enough)
    • La perfection exige des ressources infinies, donc un système peut toujours être amélioré
    • Voir la loi 13

Loi 15 (loi de Shea) — L’interface est essentielle

  • « The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. »
    • La capacité à améliorer une conception se situe principalement au niveau des interfaces, qui sont aussi l’endroit idéal pour tout gâcher
  • De nombreux ingénieurs/techniciens comprennent très bien un seul système
  • Il est rare de trouver quelqu’un qui comprenne vraiment bien plusieurs systèmes différents
    • Exemple : dans les systèmes où les interactions entre matériel complexe et logiciel sont importantes, les problèmes surviennent généralement aux interfaces

Loi 16 — Ne pas vouer un culte aux analyses passées

  • « The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours. »
    • Les personnes qui ont réalisé auparavant une analyse similaire n’avaient pas un accès direct à la sagesse des âges ; il n’y a donc aucune raison de croire davantage leur analyse que la vôtre, et encore moins de présenter leur analyse comme la vôtre

Loi 17 — La fiabilité des publications

  • « The fact that an analysis appears in print has no relationship to the likelihood of its being correct. »
    • Le fait qu’une analyse soit publiée n’a aucun rapport avec la probabilité qu’elle soit correcte
  • Opinion célèbre des années 1970 :
    • « 1200 baud est probablement la vitesse maximale qu’un modem téléphonique pourra atteindre »
    • Connue aussi par la formule « Coding is dead »
    • La Trellis coded modulation a porté cette vitesse jusqu’à 50kbps dans les années 1990

Loi 18 — Le double tranchant de l’expérience passée

  • « Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though. »
    • L’expérience passée est excellente pour garder les pieds sur terre, mais trop de réalité peut condamner une conception qui aurait autrement eu de la valeur

Loi 19 — L’importance de l’humilité

  • « The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up. »
    • Il y a très peu de chances que vous soyez immensément plus intelligent que tous les autres dans le domaine ; si votre analyse indique une vitesse terminale égale au double de la vitesse de la lumière, vous avez peut-être inventé le warp drive, mais il est bien plus probable que vous vous soyez trompé

Loi 20 — L’importance de la présentation

  • « A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately. »
    • Une mauvaise conception avec une bonne présentation est condamnée à terme ; une bonne conception avec une mauvaise présentation est condamnée immédiatement
  • Exemple : Avro C102 — deuxième avion de ligne commercial à réaction au monde (avec 13 jours d’écart)
    • Annulé pour soutenir le développement de l’Avro Arrow

Loi 21 — La nature de l’éducation

  • « Half of everything you hear in a classroom is crap. Education is figuring out which half is which. »
    • La moitié de ce que vous entendez en classe ne vaut rien ; l’éducation consiste à comprendre quelle moitié est laquelle
  • Cela ne veut pas dire que les professeurs essaient délibérément de faire perdre 50 % du temps
    • Il s’agit d’essayer de deviner quelles compétences seront nécessaires dans un domaine en évolution rapide
  • Exemple : informatique quantique
    • Ce sera peut-être un savoir indispensable pour travailler comme ingénieur au cours des 20 prochaines années, ou peut-être seulement un sujet d’intérêt académique jusqu’aux années 2030

Loi 22 — L’importance de la documentation

  • « When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.) »
    • En cas de doute, documentez. Les exigences de documentation atteignent leur maximum juste après la fin d’un programme
  • Si vous ne pouvez pas résoudre le problème, ne cachez pas votre ignorance
    • Documentez la cause du problème
    • Quelqu’un d’autre pourra peut-être trouver un moyen de le résoudre

Loi 23 — Le caractère fictif des plannings

  • « The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. »
    • Le planning que vous élaborez semblera être une pure fiction jusqu’au moment où votre client vous licenciera pour ne pas l’avoir respecté

Loi 24 — La structure de découpage du travail

  • « It's called a 'Work Breakdown Structure' because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it. »
    • On appelle cela une Work Breakdown Structure parce que le travail restant continue d’augmenter jusqu’à provoquer un effondrement (Breakdown), à moins de lui imposer un minimum de structure

Loi 25 (loi de Bowden) — Analyse après un échec de test

  • « Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along. »
    • Après un échec de test, il est toujours possible d’affiner l’analyse pour montrer que les marges étaient négatives depuis le début
  • Exemples : rapports d’accident du Bureau canadien de la sécurité des transports et de la Federal Aviation Administration (FAA)
  • Certains échecs sont dus à un manque d’imagination (paraphrase de Frank Borman)
  • On pardonne aux ingénieurs de faire des erreurs, mais pas de les dissimuler

Loi 26 (loi de Montemerlo) — Ne faites rien de stupide

  • « Don't do nuthin' dumb. »
    • Ne faites rien de stupide
  • Une règle étonnamment difficile à suivre dans la pratique de l’ingénierie
  • N’oubliez pas les bases
  • Clarifiez vos priorités

Loi 27 (loi de Varsi) — Les plannings ne vont que dans un sens

  • « Schedules only move in one direction. »
    • Les plannings ne bougent que dans un seul sens
  • Prévoyez de la marge pour les problèmes et les difficultés
    • Échec de test
    • Plus tard, urgence familiale
  • Quelqu’un d’autre peut livrer en retard un produit nécessaire sans que ce soit votre faute
  • Laissez toujours une marge de calendrier pour vous et votre équipe

Loi 28 (loi de Ranger) — Il n’existe pas de lancement gratuit

  • « There ain't no such thing as a free launch. »
    • Un lancement gratuit, ça n’existe pas

Loi 29 (loi de gestion de programme de von Tiesenhausen) — Estimation des coûts et du temps

  • "Pour obtenir une estimation précise des exigences finales du programme, multipliez les estimations initiales de durée par pi, et décalez la virgule des estimations de coût d'un rang vers la droite."
    • Pour obtenir une estimation précise des exigences finales du programme, multipliez les estimations initiales de durée par π et décalez la virgule des estimations de coût d'un rang vers la droite

Loi 30 (loi de conception d'ingénierie de von Tiesenhausen) — l'influence du concept artistique

  • "If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept."
    • Si vous voulez avoir un effet maximal sur la conception d'un nouveau système d'ingénierie, apprenez à dessiner ; les ingénieurs finissent toujours par concevoir le véhicule pour qu'il ressemble au concept initial de l'artiste

Loi 31 (loi du développement évolutif de Mo) — les limites fondamentales de la technologie

  • "You can't get to the moon by climbing successively taller trees."
    • On ne peut pas aller sur la lune en grimpant à des arbres de plus en plus hauts
  • Il est utile de comprendre les limites fondamentales d'une technologie ou d'une approche

Loi 32 (loi de la démo d'Atkin) — la loi de Murphy

  • "When the hardware is working perfectly, the really important visitors don't show up."
    • Quand le hardware fonctionne parfaitement, les visiteurs vraiment importants ne se montrent pas

Loi 33 (loi de planification des programmes de Patton) — l'importance de l'exécution

  • "A good plan violently executed now is better than a perfect plan next week."
    • Un bon plan exécuté avec vigueur maintenant vaut mieux qu'un plan parfait la semaine prochaine
  • Erreur fréquente dans l'industrie : attendre une technologie « parfaite »
    • Pendant ce temps, un concurrent s'empare du marché

Loi 34 (loi de planification des tâches de Roosevelt) — exécution réaliste

  • "Do what you can, where you are, with what you have."
    • Faites ce que vous pouvez, là où vous êtes, avec ce que vous avez
  • À moins d'être un auteur de SF, concevoir pour une technologie qui n'existe pas n'a aucun sens

Loi 35 (loi de conception de de Saint-Exupéry) — la conception parfaite

  • "A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
    • Un concepteur sait qu'il a atteint la perfection non pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retirer

Loi 36 — élégance, efficience et efficacité

  • "Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective."
    • N'importe quel ingénieur ordinaire peut concevoir quelque chose d'élégant ; un bon ingénieur conçoit des systèmes efficients ; un grand ingénieur les conçoit pour qu'ils soient efficaces
  • Conception élégante (Elegant design) : système standard d'adduction d'eau urbain
  • Conception efficiente (Efficient design) : système d'adduction d'eau de New York
  • Conception efficace (Effective design) : systèmes d'irrigation des civilisations autochtones d'Amérique du Nord et du Sud (dont certains fonctionnent depuis plus de 1 000 ans)

Loi 37 (loi de Henshaw) — des lignes de responsabilité claires

  • "One key to success in a mission is establishing clear lines of blame."
    • L'une des clés du succès d'une mission est d'établir des lignes de responsabilité claires
  • Il faut assumer la responsabilité de ses actions et de ses décisions
  • Ne faites pas confiance à un ingénieur (ou à quiconque) qui refuse d'assumer ses responsabilités

Loi 38 — les capacités déterminent les exigences

  • "Capabilities drive requirements, regardless of what the systems engineering textbooks say."
    • Quoi qu'en disent les manuels de systems engineering, ce sont les capacités qui déterminent les exigences
  • L'essentiel est de reconnaître quelles nouvelles capacités sont en cours de développement :
    • années 1950 : transistor
    • années 1960 : circuit intégré
    • années 1970 : microprocesseur
    • années 1980 : ordinateur personnel
    • années 1990 : Internet
    • années 2000 : informatique sans fil/mobile

Loi 39 — ne pas développer de nouveau lanceur

  • Les trois clés pour maintenir un nouveau programme spatial habité à faible coût et dans les délais :
    1. Pas de nouveau lanceur
    2. Pas de nouveau lanceur
    3. Ne décidez sous aucun prétexte de développer un nouveau lanceur
  • Il faut éviter la tentation de croire qu'un produit entièrement nouveau sera toujours meilleur que l'évolution d'un produit existant

Loi 40 — l'espace ne pardonne pas

  • "Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)"
    • L'espace est un environnement totalement impitoyable ; si vous ratez l'ingénierie, quelqu'un meurt (et il n'y a pas de points partiels parce que l'essentiel de l'analyse était juste...)
  • Grandes catastrophes liées au contrôle de l'ingénierie :
    • Fukushima, Tchernobyl
    • De Havilland Comet (la raison pour laquelle les hublots des avions de ligne commerciaux ont des angles arrondis)
    • Eastern Airline Flight 401 (le pilote automatique a conduit un avion de ligne commercial dans les Everglades)
    • Therac-25 (appareil canadien de radiothérapie)
  • Paraphrase de Richard Feynman : "On ne peut pas tromper la nature (Nature cannot be fooled)"

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.