Les Lois de Murphy : Informatique
Évolution informatique
Loi de Murphy-Turing
À plus que les ordinateurs deviennent intelligents, à plus que c’est des emmerdeurs.
*
Syndrome de l’Acheteur de la Veille
Le prix d’un ordinateur baisse de 50% le lendemain de son achat.
*
Loi de Gates
Tous les dix-huit mois, la vitesse des logiciels est divisée par deux.
*
Loi des Évolutions synchronisées
Les logiciels deviennent de plus en plus lent, et ceci plus vite que le hardware ne devient plus rapide.
*
Premier Syndrome d’Intel
Tout ordinateur est obsolète au plus tard à son déballage.
*
Théorème d’Obsolescence de Madrau
Tout matériel informatique acheté à un instant t est obsolète à un instant t+epsilon, avec limite de epsilon quand t croît égale zéro.
*
Loi de l’Upgrade de Why
À faire évoluer qui un disque dur par là, un écran par ci, la carte mère, etc. d’une vieille machine, il vous en coûtera au final entre le double et le triple du prix d’une machine neuve équivalente au moment de la première évolution
*
Second Syndrome d’Intel
Un microprocesseur est obsolète dès la début de sa fabrication en série.
*
Lois sur la Perte de Performance des Ordinateurs en Entreprise de Donald
I. Un PC devient lent et difficile à utiliser
dès que celui d’un des autres employés du service a été remplacé par un neuf.
II. Plus le nombre de machine neuves aux alentours croît,
plus un PC devient obsolète pour finir par être rapidement inutilisable.
*
I. Un PC devient lent et difficile à utiliser
dès qu’un membre de la famille, un ami ou un voisin reçoit celui qu’il vient d’acheter.
II. Plus le nombre de machine neuves dans l’entourage croît,
plus un PC devient obsolète pour finir par être rapidement inutilisable.
*
Première Loi de la Programmation informatique
Avant même de fonctionner, tout programme est déjà obsolète.
*
Seconde Loi de la Programmation informatique
Tout nouveau programme coûte plus cher et est plus lent à faire tourner que l’ancien.
*
Loi des Mises à Jour
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée.
*
Loi de van Tassel
« Compatibilité ascendante » signifie que toutes les erreurs de conception originelles sont conservées.
*
Syndrome d’OS/2
De plusieurs programmes ou systèmes en concurrence, le plus performant n’est jamais retenu comme standard.
*
Loi du Standard reconnu
Le « standard de l’industrie » n’a rien d’un standard reconnu et établi.
- Il est fermé (démerdez-vous pour le lire sans raquer auprès de l’éditeur).
- L’utilisateur ne s’aperçoit même pas qu’il tresse la corde pour le pendre.
- Ni que d’autres standards, réels eux, existent.
*
Loi Standard
Ce qu’il y a de bien avec les standards, c’est qu’il y en a beaucoup entre lesquels on peut choisir.
*
Loi de Blaauw
La technologie en place tend à se maintenir malgré la nouvelle technologie.
*
Loi du TO7-TO9-MO5 de Jeg
Tout plan informatique pour tous est bénéfique à tous les placards.
*
Loi de l’Équipement de Sefas
Plus le matériel informatique est moderne,
plus le tableau à papier est branlant.
Informatique quotidienne
Interrogation par Gonçalvès
Pourquoi raconter des conneries sur l’informatique, alors que l’informatique elle-même est une grande connerie ?
*
Remarque de McLuhan
Grâce à l’ordinateur, on peut faire plus rapidement des choses qu’on n’aurait pas eu besoin de faire sans ordinateur.
*
Loi du Chaos Informatique
L’informatique, ça tient du chaos : une fois ça marche, une fois ça foire, tu sais pas pourquoi, c’est juste que tu viens de changer de lobe sur l’attracteur étrange.
*
Rappel sur le Chaos Informatique
Rappelez-vous que ce n’est pas un hasard si l’informatique et la théorie du chaos se sont développées simultanément.
*
Loi de Burn appliquée à l’Informatique
Garbage in, garbage out.
*
Si on fait passer des bêtises dans un ordinateur, il n’en sortira que des bêtises.
Mais ces bêtises, ayant été traités par une machine très chère, sont en quelque sorte « anoblies » et personne n’ose les critiquer.
*
Loi de Sattinger
Ça marcherait mieux si vous le branchiez (en dernier ressort basculer l’interrupteur).
*
C’est après avoir pleuré des heures « putain pourquoi mes deux PCs ne se voient pas ???? Finalement c’est de la daube Linux ! » que vous vous rappelez que les deux machines ne sont pas connectées.
*
Loi électroinformatique de Benthabet
C’est lorsque votre programme aura tourné 5 heures sur les 6 qu’il prend que les plombs sautent.
*
Merde, moi y manquait plus que 3 jours de calculs.
*
Loi de la Sauvegarde de Robert
C’est après avoir bossé aux modifs d’un fichier pendant trois heures que vous vous rendez compte qu’il est en lecture seule, et que vous n’avez aucun autre moyen de l’enregistrer.
*
La perte d’une sauvegarde met automatiquement en péril l’original.
*
Fruit de l’Expérience d’Hier Soir d’Elie
Ne renversez pas une pile de verres vides près de votre portable...
il se pourrait bien que le verre du dessus soit plein.
*
Conseil de Cahn
Quand tout le reste a échoué, lisez le mode d’emploi.
Ajout :
C’est à ce moment qu’on se rend compte qu’on l’a jeté avec l’emballage.
*
Loi électro-informatique portative de Bernadat
C’est le jour où vous avez enlevé la batterie de votre portable pour la décharger qu’une microcoupure surviendra et vous fera perdre 4 heures de travail.
*
Remarque ambidextre de Bailleul
Quand vous tapez un texte et que le téléphone sonne, vous avez toujours une combinaison de touche avec Ctrl de gauche - P à taper.
Corollaire : La souris est à droite et le téléphone aussi.
*
Lois de Dimensionnement de Gates
La taille d’un document sauvegardé par un programme est proportionnel à l’exponentielle du numéro de version dudit programme.
Exception : Proportionnalité simple pour les produits non Micro$oft.
*
Loi des Screensavers de Gonçalvès
L’économiseur d’écran se déclenche toujours lorsque l’on veut écrire quelque chose.
Extension : Et on déclenche le plus souvent par erreur le mode « veille ».
*
Loi des Hackers
La légitimité d’une copie est inversement proportionnelle à son intérêt.
*
Loi du Graveur de Ben
Ça prend toujours plus de temps de graver un CD pour les autres que pour soi-même.
*
Loi de Cash
C’est trois secondes après avoir cliqué au hasard sur l’icône tc69.gif que votre copine surgira à l’improviste dans la salle info et tombera sur Tabata Cash en pleine action et en plein écran (21 pouces).
Corollaire :
C’est deux secondes après avoir regroupé un troupeau de visiteurs devant une station de travail qu’un incident au mieux similaire se produira.
*
Lois de Jeg-Markus-Hohmann-Barral de la Visite-surprise-du-chef-et-de-la-fenêtre-Windows
1) Le temps de fermeture d’une fenêtre Windows qui affiche vos distractions préférées (comme le courrier de la murphypro) est toujours plus long que d’habitude lorsque vous voyez votre patron venir.
2) Ce temps est directement proportionnel à la gêne qu’il provoquera et tout à fait maximal si l’affichage est de type « planche anatomo-morphologique féminine ».
Pour ces cas là, Micro$oft a prévu le « gel » de l’application, voire de Windows : la souris devient inopérante, l’image affichée se fige, et même « Ctrl-Alt-Del » ne marche plus !
4) Vous pouvez toujours faire disjoncter votre compteur pour supprimer toute alimentation électrique. Mais là aussi, c’est prévu : l’onduleur, le groupe électrogène, etc veillent !
5) Et bien sûr, le moniteur est directement alimenté par le PC et n’a pas de bouton ON/OFF sur la face avant !
*
Loi des Immeubles de Delcourt
Ils sont configurés de telle manière qu’à n’importe quelle heure de la journée le soleil puisse se refléter sur votre écran (éventuellement après une réflexion sur plusieurs fenêtres).
Corollaire : Vous êtes obligé de vous placer dos à la porte.
Société et informatique
Loi de l’Animal informatique de Coste
Le chien a un maître, le chat un serviteur, l’ordinateur un esclave.
*
Sainte Trinité maudite
Il y a trois manières de se ruiner : les femmes, le jeu et l’informatique.
Les deux premières sont les plus agréables, la troisième est la plus sûre.
*
Postulat inconscient des Informaticiens
Les PC, c’est comme les femmes.
Quand on n’en a pas, on ferait n’importe quoi pour en avoir.
Quand on en a, on se ruine pour les entretenir.
*
Neuvième Loi de la Programmation informatique
Il est économiquement plus faisable de fabriquer un ordinateur que de le programmer.
*
Hypothèse d’Olitec
Une des raisons qui explique que les ordinateurs accomplissent plus de travail que les humains, c’est que eux n’ont pas à s’arrêter pour répondre au téléphone.
*
Loi de Hunt
Ne faites jamais confiance à un ordinateur que vous ne pouvez pas balancer par la fenêtre.
*
Transcendance de Von Neumann
L’erreur est humaine mais un véritable désastre ne peut être qu’informatique.
*
Observation de Turnaucka
L’erreur est humaine, mais pour provoquer une vraie catastrophe, il faut un ordinateur.
*
Règle d’Horowitz
Un ordinateur fait autant d’erreur en 2 secondes que 20 humains en 20 ans.
*
Suggestion de Dumas
Un ordinateur vous permet de faire des erreurs encore plus rapidement que n’importe quelle autre invention, à l’exception peut-être des armes à feu et de la téquila.
*
Doute de Markus
Puisqu’au dire de certains, l’informatique est trop sérieuse pour être laissée entre les mains des informaticiens, je me demande si elle n’est pas trop dangereuse entre les mains d’un non-informaticien.
*
Première Loi de Gilb de la Non-Fiabilité
Les ordinateurs ne sont pas fiables, mais les humains le sont encore moins.
Corollaire :
À la source de toute erreur dont on accuse l’ordinateur, on trouvera au moins deux erreurs humaines, dont celle de rejeter la faute sur l’ordinateur.
*
Seconde Loi de Gilb de la Non-Fiabilité
Tout système dont la fiabilité dépend d’un être humain n’est pas fiable.
*
Loi de Financement de Coste
L’ordinateur est la source de tous nos maux, mais aussi de bien des bénéfices.
*
Il y a trois grands mensonges en informatique :
- Ça marche.
- C’est compatible.
- Ça sort bientôt.
*
Lois du Mot de Passe de Verdes
Plus il est ridicule
et plus vous vous sentirez ridicule lorsque vous aurez à le donner.
Plus il est éloigné de votre personnalité,
moins les autres pourront le trouver,
mais plus vous aurez de chances de l’oublier.
Plus vous le changez souvent
et moins les autres pourront le trouver,
mais plus vous aurez de chances de l’oublier.
Dans tous les cas vous finirez par l’écrire sur un post-it caché dans le premier tiroir du bureau.
Addendum du Snide :
S’il n’est pas ridicule, il est inmémorisable et vous aurez l’air ridicule en ayant un postit collé au dos du clavier.
*
Loi du Programme Miracle de Bourmault
C’est après plusieurs jours d’analyse et de développement aboutissant à un programme modulable bien construit que tout le monde pourra appeler facilement, et qui répondra à des besoins futurs par des évolutions faciles, que l’on vous apprend que vous pouvez le jeter à la poubelle parce qu’un tel programme existe déjà dans un autre service.
Corollaire : Cet autre programme est bien sûr une merde technique.
Boot
Aberrations du Boot PC
"Keyboard not found, Press any key to continue." ou : "Keyboard error, F11 to resume."
Plantages
Ce qu’on obtient quand la Loi de Murphy rencontre la Loi de Moore.
*
Règle de Base n°1 de l’Informatique selon Jeg
Ne pensez jamais que ça va marcher au moment où vous en aurez le plus besoin.
Corollaire :
Plus vous auriez besoin que ça marche,
plus cela augmente les chances que ça plante.
*
Attention de Cupertino
Un ordinateur vous accueille au travail par un « Bienvenue » et une musique et vous dit que la journée de travail est finie par « Erreur système - Ordinateur bloqué ».
*
Proverbe informatique
L’erreur est humaine,
mais pardonner est hors des capacités du système d’exploitation.
*
Eventualités du PC
Ce n’est pas parce qu’il est éteint que mon PC ne fonctionne pas.
Ce n’est pas parce qu’il est allumé que mon PC fonctionne.
*
Si vous avez oublié de sauver votre travail de la matinée en partant prendre la pause café, vous pourrez le refaire (votre station aura planté).
Corollaire murphyque :
En plus, la machine à café sera en panne ce jour-là.
*
Loi variationnelle de Norton
Vous ne vous doutez pas de la taille que peut avoir la banque de messages d’erreur différents d’un programme.
*
Loi informatique du Temporaire permanent de Moine
Un ordinateur planté, c’est plusieurs gros fichiers temporaires qui deviennent permanents.
*
Lois du Commercial informatique de Dauché
La probabilité qu’une installation de n’importe quoi mène à un blocage total et irrémédiable de l’ordinateur est inversement proportionnelle au temps disponible.
Dans le cas d’un portable destiné aux présentations commerciales, la probabilité de plantage est exponentiellement proportionnelle à l’importance du rendez-vous.
Évidemment, si d’autres ordinateurs sont disponibles, ils tomberont tous en panne en même temps.
Les seules machines miraculeusement disponibles ne comporteront que des versions périmées du logiciel à présenter, ou bien des versions trop récentes dont les modules sont subtilement incompatibles.
*
Loi d’Ettrich
(Inverse de l’Effet Bonaldi)
Si vous attendez impatiemment qu’une version alpha d’un logiciel se plante dans une démonstration devant un large public,
tout se déroulera impeccablement.
Corollaire :
Un plantage ne s’obtiendra pas devant des gens compréhensifs prêts à le pardonner.
Il arrivera devant des sceptiques.
*
Lois de la Présentation Informatique de Lignon
Si vous avez une démonstration à faire sur station, le programme plantera.
Si le programme ne plante pas, le réseau ramera tellement que vous aurez l’impression que ça a planté.
Si le programme ne plante pas, ni le réseau, c’est la station qui plantera au milieu de votre démonstration.
Si ni le programme, ni la station, ni le réseau ne plantent, l’écran aura une résolution trop faible pour tout afficher correctement.
Si la démonstration fonctionne correctement, vous marcherez dans les fils en partant et entrainerez la station avec vous.
*
Si vous sortez des produits buggés, ils vous en remercieront en plantant en public.
*
Application à la Présentation informatique de l’Effet Bonaldi
Si un programme passe le test final avec succès, il plantera forcément pendant sa présentation.
*
Si au cours d’un développement vous voulez montrer que vous avez besoin d’un peu plus de temps pour corriger un bug, alors lors de la présentation le programme marchera même si cela n’est théoriquement pas possible.
*
Loi d’Access
Quoique tu fasses, ça plantera et de préférence chez le client situé le plus loin de ton bureau et sans e-mail.
*
Loi de la Montée en Puissance des Ordinateurs de Tomezzoli
Plus un ordinateur est puissant, plus il exécute d’instructions en un temps donné.
Plus un ordinateur exécute d’instructions, plus il y a de risque d’en exécuter une qui plante le système.
Premier Corollaire :
Un Pentium II® sous Windows 95 plante plus souvent qu’un 286 sous DOS.
Second Corollaire :
Plus un ordinateur est cher, plus Windows est buggé.
Conclusion :
Ne dilapidez pas votre argent en achetant un ordinateur plus puissant.
*
Loi des Plantages de Moine
Si vous mettez 30 novices devant un ordinateur équipé de Windows, vous aurez 30 manières différentes de planter Windows.
*
Opposition de Pieryv
C’est lorsque vous n’avez rien envie de faire de particulier sur votre ordinateur qu’il fonctionne le mieux.
*
Loi de Vial
Un ordinateur ne plante que le jour où son utilisateur néglige de faire une sauvegarde toutes les demi-heures.
Si la sauvegarde était automatique (merci Word 6), le plantage aura lieu pendant cette sauvegarde.
*
Si la sauvegarde a marché, le disque dur ne redémarrera plus.
Hardware
Loi de Goodin
Le nouveau hardware rendra l’âme dès que l’ancien aura été jeté.
*
Extension soft de Why de la Loi de Goodin
Quand on a une nouvelle bécane, elle se plante (d’où formatage) une fois que toutes les données de l’ancien système y auront été transférées (après dix pénibles tentatives) et que celui-ci aura été reformaté ou expédié sous d’autres cieux.
*
Loi de la Flash-ROM
La probabilité d’une coupure brusque de courant augmente considérablement quand on fait une update de Flash-ROM.
*
Seconde Loi de la Disquette de Léon-dit-Volny
Le climat guyanais convient moins aux disquettes qu’aux moisissures.
*
Loi des Biscottes de Moine
Il est préférable que le lecteur de disquettes contienne au plus une disquette à un moment donné que plusieurs.
Précision de Léon-dit-Volny :
... et de préférence insérée dans le bon sens.
*
Loi de Fiabilité des disquettes de Delavaquerie
Un lecteur de disquette n’est fiable que six mois, une disquette le temps de cinq cycles lecture/écriture.
*
Loi des Espaces creux de Choligne
C’est lorsque vous avez installé un composant dans un PC que vous vous apercevez que les nappes sont trop courtes.
Ou inexistantes.
Première corrélation :
Si la nappe est assez longue, c’est que ce n’est pas la bonne.
Seconde corrélation :
Si la nappe est trop courte, elle le sera encore plus une fois que vous aurez tout démonté pour faire de la place.
Exception :
Si le PC est un serveur, alors nécessairement la nappe sera assez longue, ce sera la bonne, et le serveur plantera.
*
Soient trois extensions A, B, et C.
Si installer A ne plante pas l’ordinateur, qu’installer B ne plante rien non plus, et qu’installer C ne plante toujours rien,
alors :
soit vous avez oublié de démarrer la bécane,
soit, ce qui est plus probable, l’extension C rendra incompatibles les extensions A et B, ce qui fera planter le tout.
*
Observation Fondamentale de Lyall
La patte la plus importante d’une puce est celle qui manque.
*
Conséquence de Raleigh
Nouveau hardware, nouveaux problèmes.
*
Ce n’est pas parce que deux périphériques n’ont aucun rapport entre eux que Windows ne cassera pas l’un à l’installation de l’autre.
*
Marque de Wide’z & Mat
L’IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu’un voulant le défier.
*
Loi Sanglante de Miod
Dans le métier d’assembleur, ce sont toujours les boîtiers les plus agréables à monter qui sont les plus coupants.
*
En plus ça coupe toujours aux endroits qui saignent le plus.
*
Loi du Périphérique Hot-Swappable de Bernadat
Tout type de périphérique informatique que vous avez l’habitude de brancher/débrancher à chaud vous grille dans les mains le lendemain du jour où vous venez d’apprendre qu’il n’était pas hot-swappable.
*
Abominations de Hewlett-Packard-Bell-Felber
I.
Démonter n’importe quel composant d’un PC de marque implique le désossage complet de la machine.
Corollaire :
Si un composant défectueux ou trop limité doit être emprunté à une autre machine, les deux PCs seront de marque.
Complication du Corollaire :
...de marques différentes.
II.
Un deuxième disque dur est soit trop petit (en Go) pour être satisfaisant, soit trop grand (en pouces) pour rentrer.
Disques durs, disquettes et sauvegardes
Loi des Disques dur de Thompson
L’état de repos d’un disque est : plein.
*
Principe du Trop Plein de Jeg
Tout disque dur, quelque soit sa taille, sera toujours rempli d’un nombre invraisemblable de fichiers, applications, etc., tous indispensables... et bien vite saturé.
*
Principe de Jeg du Truc-qui-se-remplit-toujours-quand-on-voudrait-pas-qu’il-se-remplisse
À l’acquisition du disque, on se dit que « de toute façon on n’arrivera jamais à remplir tout ça ».
Quelques mois après, on se dit que « tout est indispensable, il n’y a rien qu’on puisse effacer ».
*
Loi de Pollution inéluctable des Disques durs de Servotte
Installez et désinstallez, il en restera toujours quelque chose !
*
Loi d’Avet
Un disque dur qui foire, ça n’arrive jamais.
Sauf quand ça arrive...
*
C’est une erreur de laisser remarquer à un disque dur quelle est la date de la dernière sauvegarde.
*
Un sabordage du disque dur se produit la veille du jour où la sauvegarde est prévue.
*
Première Loi de Backup
La probabilité d’un crash du disque dur augmente de manière exponentielle avec l’âge de la dernière sauvegarde complète.
*
Automatisme de Simon
Projetez de faire la sauvegarde mensuelle demain matin, le disque dur crashera ce soir.
*
Seconde Loi de Backup
C’est généralement lorsque le disque dur plante qu’on se rend compte qu’on a oublié de le sauvegarder.
*
Loi de Messiant du MTBF
(Murphy Time Between Faults)
Le temps s’écoulant entre l’installation d’un PC et son premier plantage est très légèrement supérieur à celui mis pour y copier des données importantes.
*
Théorème probabiliste du MTBF
La probabilité de panne est exponentiellement proportionnelle à l’importance des données.
*
Relation d’Hurbain du MTBIF
Le temps de lâchage après installation d’une vieille machine est inversement proportionnel au temps d’installation de la dite machine.
*
Égalité d’Heisenberg appliquée au MTBF
Soit I la mesure de l’importance des données :
MTBF * I = Constante
*
Loi de Relativité temporelle de la Sauvegarde de Miod
(Signature octobre-novembre 97)
À quoi bon sauvegarder son travail puisque les plantages surviennent toujours juste avant la sauvegarde ?
Retarder le moment de la sauvegarde retarde le plantage.
*
Loi du GigaOctect de Michel
Augmenter la taille de son disque dur, ne fera qu’accroître le volume de données non sauvegardées perdues lors du prochain crash.
*
95ème Malédiction de la Sauvegarde
Le nombre de fois où vous avez repoussé à plus tard l’enregistrement de Windows sur disquettes sera proportionnel à la chance que tout votre système disparaisse avec le contenu du disque dur.
*
Loi de Segers
Si ton disque dur te laisse tomber, tu ne trouveras pas les disquettes sur lesquelles tu as sauvegardé tes fichiers importants.
Si tu trouves les disquettes, elles seront illisibles.
*
Loi de PkZip
(ou Théorème d’Arj)
Lors de toute copie sur disquettes d’un fichier de plus de 1,4 Mo via un compresseur comme PkZip ou Arj, il n’y aura que 10 ko occupés sur la dernière disquette.
*
De toute façon, ça n’a aucune importance, c’est à la fin de la première disquette que se trouveront les secteurs défectueux.
*
Mythe réaliste de la Sauvegarde
La seconde bande ou disquette de toute sauvegarde est mauvaise.
Réalité : Seuls sont mauvais les secteurs, blocs, bandes où se trouvent les données que vous voulez récupérer.
*
Loi du Fichier perdu de Jeg
Si vous cherchez un fichier et que vous possédez 75 disquettes,
alors il est sur la dernière que vous allez insérer dans le lecteur.
Et bien sûr, c’est cette disquette là qui plantera.
Précision de Léon-dit-Volny :
S’il n’y était pas, on le retrouvera sûrement quand on n’en aura plus besoin en cherchant un autre fichier dans les 75 disquettes.
*
Première Loi de la Disquette de Léon-dit-Volny
C’est toujours quand on a un besoin urgent d’une disquette qu’on s’aperçoit au formatage que celle-ci a des secteurs défectueux.
*
À condition, bien sûr, que vous ayez pensé à la formater...
*
Loi des Cassettes sur MO5
Un logiciel tenant sur plusieurs cassettes sera systématiquement inutilisable après l’achat : une des cassettes est illisible.
*
Loi de la Sauvegarde automatique de Jeg
Toute sauvegarde automatique se fera au moment où vous ne vouliez pas qu’elle se fasse, pour écraser un ancien fichier que vous avez oublié de renommer, par exemple.
*
Loi du CDROM
Un CDROM est un puissant média capable de stocker 640 Mo de données sous un format pratique et peu coûteux.
Un lecteur de CDROM permet au programme d’installation de les copier intégralement sur votre disque dur.
Bases de données
Loi de l’Indéterminisme SQL d’Oracle
Toute requête complexe optimisée en production finira par voir son chemin d’exécution changé d’office par la base de données au pire moment, de la pire manière qui soit.
Corollaire : Le problème n’existe qu’en production ; l’environnement de
développement ne permet pas de le reproduire.
Administration système
Loi de la Mise à Jour d’un OS
C’est après avoir installé la mise à jour d’un OS déjà bien capricieux que l’on s’aperçoit que ses programmes préférés ne sont pas compatibles.
*
Loi du Scandisk de Bernardat
Le temps restant estimé avant la fin d’une opération d’entretien sur un disque (scandisk, antivirus...) se bloque 5 secondes avant la fin.
*
Loi de l’Arrière-plan de Bernardat
Toute opération d’entretien sur un disque susceptible d’être effectuée en arrière plan (scandisk, antivirus...) :
- consomme des ressources machines au point que toutes les autres applications sont ralenties notablement,
- est d’une lenteur monstrueuse tant que vous ne lui avez pas rendu l’avant-plan,
- et plante votre machine alors que toutes les autres applications fonctionnent bien.
Toutes ces propriétés sont bien sûr cumulables.
*
Loi de Scandisk pour Windows©
ScanDisk a détecté une erreur en lisant le contenu de votre lecteur.
Il corrigera cette erreur plus tard. Toutefois, d’autres erreurs peuvent rester sur votre lecteur lorsque ScanDisk aura fini. Une fois le test en profondeur achevé, effectuez un test standard de ce lecteur pour être sûr que toutes les erreurs sont corrigées.
*
Euphémisme de Norton
« Réparer » un fichier vérolé veut probablement dire « euthanasier ».
*
Troisième loi de Greer
Un programme informatique fait ce que vous lui avez dit de faire, pas ce que vous voulez qu’il fasse.
*
Loi informatico-sémantique
Un ordinateur ne fait pas ce que vous voulez,
mais ce que vous lui dites.
Ceci n’a pas pas forcément grand rapport avec ce que vous croyez être en train de lui dire.
*
Axiomatique fondamentale de l’Informatique selon Bellamy
En Informatique, TOUT est possible...
Premier Corollaire : ...mais ce n’est pas toujours évident.
Second corollaire : ...surtout le pire.
*
Avertissement de Bentley
People who deal with bits should expect to get bitten.
*
Loi de Paquel
La caractéristique la plus constante de l’informatique est la capacité des utilisateurs à saturer tout système mis à leur disposition.
*
Loi du Cadeau d’Occase de Bernardat
Tout périphérique informatique qui vous sera offert ne sera pas compatible avec votre matériel actuel. Comme il s’agit d’un vieux périphérique, il nécessite une carte d’adaptation introuvable, sauf peut-être dans un magasin d’occasion, au prix de la truffe, si bien que le cadeau vous coûte plus cher que si vous aviez acheté le même matériel neuf, et beaucoup plus performant.
*
Loi de la Pérennité du « Copain qui connaît l’informatique mieux que vous »
Il ne se passe pas plus d’une demi-journée pour qu’un copain qui s’y connaît en informatique vienne sur votre bécane flambant neuve « juste pour voir » et qu’il la monopolise durant le reste de la journée pour faire des manipulations que vous ne comprenez pas alors que vous vouliez juste taper votre CV pour l’offre d’emploi superurgente parue dans le journal.
Premier Corollaire :
Il ne se passe pas plus d’une demi-journée avant que n’apparaissent des erreurs système de type 1 (qui nécessitent le reformatage du disque dur et la réinstallation de Windows). À partir de ce moment-là, votre PC ne sera plus jamais aussi performant que lors de cette première demie-journée.
Second Corollaire :
Après cette demie-journée, vous vous apercevez que le copain n’était pas un de vos copain mais seulement un vague cousin de la copine du voisin d’en-dessous.
*
Loi de l’Utilisateur
Plus vous vous refuserez à essayer de comprendre quoi que ce soit à l’informatique,
plus vous accumulerez les plantages qui vous obligeront à essayer d’y comprendre quelque chose.
*
Conseil d’Osterhode
Si ça commence à délirer, effacez et réinstallez de zéro.
*
Première Règle de Kabel
L’envergure d’un ordinateur n’est pas plus longue que son cordon d’alimentation.
*
Seconde Règle de Kabel
La zone dangereuse pour un ordinateur dépend de la longueur de son cordon d’alimentation.
*
Malédiction boutonique
Tout coup porté à un ordinateur en marche aboutit systématiquement sur le bouton ’reset’.
Corollaire : Le taux d’attraction boutonique est directement proportionnel au caractère critique de l’opération en cours.
*
Loi de l’Unformat de Yoyo
Un UNFORMAT aboutit à la récupération des données les plus inutiles (par exemple Windows).
Corollaire : La probabilité de récupération d’un fichier est inversement proportionnelle à la valeur de celui-ci.
*
Loi du Deltree *.*
Un fichier informatique est d’autant plus facile à effacer que son contenu est précieux.
*
Loi de Miod des Logiciels-qui-se-font-la-malle
Un logiciel met plus de temps à être livré que l’ordinateur sur lequel il doit fonctionner, même s’il a été commandé bien avant.
Et si le logiciel est disponible sur Internet, alors le matériel/logiciel nécessaire à la connexion subira le même sort.
*
Loi du Système boosté
L’efficacité des astuces, logicielles ou matérielles pour configurer, optimiser et accélérer votre ordi est inversement proportionnelle à la dégradation de la stabilité du système.
*
Vexation de Skulason
Si votre anti-virus favori réclame de démarrer votre PC sur une disquette propre,
alors TOUTES vos disquettes amorçables seront infectées.
*
Adage de l’Informaticien et du Galèrien
Plus on galère,
plus on s’en souvient.
*
Loi de \\|/
Quand on a le choix entre / et \\ , on choisit toujours celle dans le mauvais sens.
*
Loi du Test foiré
Plus une installation de logiciel devra être rapide et sans histoire, et sans grande importance,
plus la catastrophe conséquente sera apocalyptique.
*
Loi du Partitionnement par le Vide
Partitionnez votre disque dur pour protéger vos données des corruptions dues aux crashs de Windows, et lors d’un pépin c’est la partition données qui soufrira, et Windows restera, intact, à vous narguer.
*
Loi de la Fiabilité Absolu Conditionnelle
Un logiciel qui semble extrêmement fiable (comme un repartitionneur de disques durs) et a été utilisé sans problème depuis des mois foirera au moment le plus inattendu et celui où il fera le plus mal.
*
Énième Rappel du Backup
Plus vous êtes conscient de la nécessité des sauvegardes régulières (en partie grâce à de douloureuses expériences),
moins la place pour cette sauvegarde est disponible (merci les DD de 20 Go) et plus vos tendances procrastinatoires reprennent le dessus.
*
Loi du Logiciel fonctionnaire de Simas
Un logiciel ne voit pas d’inconvénient à refuser de fonctionner parce qu’une librairie est absente, et à refuser de l’installer parce qu’elle est déjà sur le disque dur.
Hotlines et support
Loi du Support micro de Manson
Si la panne chronique de votre PC refuse de se manifester en présence de votre support micro, c’est la preuve qu’il est très compétent.
Si au contraire la panne survient en sa présence, non seulement le support micro ne fera qu’aggraver le problème en essayant d’y rémédier, mais en plus il rejettera la faute sur le couple maudit que vous formez avec Bill Gates.
De toute façon, dans les deux cas, la défaillance de votre PC (pléonasme) ne sera pas réglée.
Corollaire de Gate$ : Plus une hotline est chère, plus elle est incompétente.
*
En informatique, seul un gourou du système sait pourquoi ça a foiré,
mais dans ce cas il se moque de savoir quand ça a foiré.
*
Loi des Achats d’Ordinateurs de Gonçalvès
Un ordinateur acheté, c’est plusieurs mois de galère.
Correction d’Andrieu : ...pour celui qui se farcit le support technique.
*
Début du long Apprentissage de l’Informatique selon Why
Quelqu’un qui s’achète un ordinateur pour la première fois aura tous les plantages possibles, mettra tout ça sur le compte de son inexpérience/incapacité et fera appel à un ami soi-disant spécialiste qui
1) n’ayant pas le temps de passer, le fera patienter deux-trois jours ;
2) une fois le crash constaté, laissera tomber la sentence : « Là je ne
comprends pas, c’est la première fois que je vois ça, le mieux c’est de le rapporter à la boutique et de le faire changer/voir ça avec eux » ;
D’où retour chez l’assembleur/distributeur (engueulade style « vous avez fait quoi ? vous avez touché au Setup, hein ?!! ») et retour à la case départ.
*
Loi de Généralisation des Problèmes informatiques de Wichlacz
Les problèmes informatiques se situent généralement entre le clavier et la chaise.
*
Redirection Circulaire du Helpdesk
Soit une adresse de helpdesk.
Soit l’adresse réelle de la personne vers qui cette adresse est redirigée.
Alors, si cette personne est en vacances, en envoyant une demande urgente à la première adresse, vous recevrez un message automatique vous informant que la personne est indisponible et que vos appels à l’aide doivent parvenir à l’adresse du helpdesk.
*
Numération de Courtois-Dauplais
Un même numéro peut cacher beaucoup de version différentes d’un même logiciel.
Systèmes d'exploitation (général)
Si vous avez supprimé tous les bugs de l’application et contourné tous ceux du compilateur, les bugs inhérents au système d’exploitation rendront l’application inutilisable plus de cinq minutes.
*
Dixième Loi de la Programmation informatique
Un système d’exploitation est une vaine tentative d’inclure ce qui a été oublié dans la conception d’un langage de programmation.
*
Loi© de ®Micro$oft ©Windows NT
Tout système d’exploitation à la réputation de fiabilité inébranlable peut être planté par la première application « hello world » d’un programmeur débutant.
Window$© et Mi©ro$oft
Loi de la Configuration de Window$©
Never change a winning team.
*
Loi de Vanhullebus
Un PC sous Windows, c’est un amas de compatibilité avec l’antiquité informatique.
*
Exception de Derouet
Windows sait tout faire, sauf fonctionner correctement.
*
Analogie de Kerdreux
Acheter un PC sous Windows, c’est comme se payer une voiture neuve amoureuse des platanes.
*
Analogie de Lang
Les logiciels sont comme le chantage : quand on commence à payer, cela ne s’arrête plus.
*
Pluralité de Derouet
Avec toutes ces mises à jour officielles et officieuses, Windows se conjugue aujourd’hui au pluriel.
Et quand je dis pluriel, je ne parle pas de diversité culturelle mais de bordel ambiant.
*
Malédiction du PC
Peu importe comment ni pourquoi, un bout de matériel ou de logiciel de votre ordinateur sera hélas estampillé Microsoft.
*
Principe de Fiabilité de Teyssier
La fiabilité d’une machine est inversement proportionelle au nombre de logiciels Microsoft qui y tournent.
*
Loi de Pornin
Des outils informatiques puissants et standards peuvent déjà exister,
mais ils ne se répandront pas avant que quelqu’un cherche à faire du pognon, avec une version buggée, sur les dos des gogos qui découvriront ça.
*
Loi de Bielling
Micro$oft, ce n’est pas tant : « nous avons enfin cette technologie pour vous » que : « vous avez enfin la machine pour le faire tourner ».
*
Aveu de Myrvold
Si nous n’avions pas mis votre ordinateur à genoux, pourquoi iriez-vous en acheter un autre ?
*
Loi de l’Informatique de Volny
C’est toujours lorsque qu’on commence à être habitué à ses softs que Microsoft trouve le moyen de tout changer avec une nouvelle version.
*
Contournez les bugs d’un logiciel ou achetez une nouvelle machine assez rapide pour le faire tourner confortablement, et immédiatement sortira la nouvelle version bien plus lourde et avec d’autres bugs.
*
But de Gates
Ce n’est pas pour utiliser, c’est pour vendre.
*
Malédiction d’Intel-Micro$oft
Soyez le leader de votre marché, et chaque imperfection de vos produits sera disséquée au journal de 20h ;
un petit concurrent pourra, lui, rester impunément dans la médiocrité.
*
Loi patissière de Gates
La notoriété et l’arrogance attirent les tartes.
*
Dégustation de Gates
Ce n’est parce qu’on est pété de thunes et qu’on a inventé des systèmes d’exploitations foireux, qu’on peut échapper à la tarte à la crème.
*
Loi de ®Micro$oft de Gonçalvès
Quelque soit l’application Micro$oft© achetée, vous devenez toujours l’heureux propriétaire d’une collection de bugs.
*
Postulat caché de Bilou
Windows plantera toujours au pire moment, en plein téléchargement, en plein travail important (de dix pages que vous n’avez pas encore sauvegardées), en pleine partie d’un super jeu (dont vous êtes en train de faire péter le high score)...
*
Délicate Attention de Gates
Vous ne savez pas trop quoi faire ce soir ?
Ne vous inquiétez pas, Windows vous demandera de gaspiller la soirée à le réinstaller !
Remarque : Valable aussi lors des soirées surchargées.
*
C’est quand votre ordinateur est éteint qu’il marche le mieux.
*
Miséricorde de Gates
Un plantage mineur de Windows est celui qui se résoud grâce à une
simple réinstallation sans « deltree c:\windows ».
*
Diktat de Gates
It’s not a bug, it’s a feature.
*
Colère de Cavey
1- Tout produit commercialisé par Micro$oft obéit aux lois de Murphy.
C’est particulièrement vrai s’il s’agit d’un système d’exploitation.
2- La loi ci-dessus est un pléonasme.
*
Malédiction bienfaisante de Géhännü
Vous avez acheté un programme pour Windaube ?
Dommage, sous Linux il était plus puissant et gratuit.
*
Malédiction de Vallat-Gates
Une fois que vous avez une solide réputation de méchant vilain pas beau qui pue, toute allusion à une action ni sordide, ni ignoble, ni même méchante, même des années auparavant, rencontre l’incrédulité générale.
*
Axiome de Djebel
Microsoft, parce que j’ai pas le choix.
Unix / Linux
Loi de Berkeley-Anderson
Nous ne croyons pas que ce soit une coïncidence si le LSD et Unix sont sortis tous les deux de la même université (Berkeley).
*
Théorie des Catastrophes appliquée à Unix
Il y a deux types d’administrateurs :
- celui qui a fait une grosse connerie sous root,
- et celui qui va en faire une.
*
Loi de Bujon
Quand on se met à Linux, vaut mieux avoir BEAUCOUP d’amis.
*
L’expérience prouve toutefois que c’est lorsqu’on dit « tu vas voir, linux c’est facile » que se produisent les pannes.
*
Loi de Stween du kernel Linux
La version X.Y.Z+1 est publiée le jour où vous compilez enfin la X.Y.Z.
Corollaire : La version suivante contient un patch de sécurité critique.
Intelligence artificielle
Principe d’IBM
Les machines doivent marcher.
Les gens doivent penser.
*
Analyse d’Eniac
Les ordinateurs ne sont pas intelligents.
Mais ils pensent qu’ils le sont.
*
Loi de Kahï
« Intelligence Artificielle » signifie que la machine est capable de prévoir à quel moment elle doit tomber en panne pour optimiser votre stress.
*
Intuition géniale de Manson
Un logiciel d’intelligence artificielle est très compliqué à mettre au point.
Une méthode plus simple pour y parvenir consiste à écrire un programme de connerie naturelle, et à la fin du programme, d’ajouter l’instruction {votre_programme} * (-1).
Puissance
Loi de Grosch
La puissance de calcul augmente comme le carré du coût.
Si vous voulez le faire deux fois moins cher, vous devrez le faire quatre fois plus lent.
*
Dilemme tertiaire du Développement
Rapide, pas cher, bien fait : n’en choisissez que deux.
*
Loi logicielle de Lynx
Un logiciel robuste est limité, un logiciel puissant est instable.
Addendum de Bernadat : Sauf chez Microsoft, qui arrive à faire des logiciels à la fois instables et limités.
*
Loi du RSA 56
Ne sous-estimez jamais la capacité de calcul des machines dont dispose votre ennemi.
*
Loi du RSA 128
Ne sous-estimez jamais la capacité de calcul des machines dont dispose votre ennemi.
ERP et Informatique d'entreprise
Loi du Versioning chaotique
Un 0.0.0.1 de différence de version d’un logiciel majeur ne veut pas dire que les différences dans votre configuration ne seront pas énormes.
Programmation et bugs
Loi des Langages informatiques
Il n’y a pas de langage informatique dans lequel vous ne puissiez écrire de mauvais programme.
*
Maintenant, grâce à Microsoft et à la simplification de ses systèmes via les assistants, tout le monde est capable de créer des systèmes dangereux.
*
Dicton du CVS
Commit du soir, espoir.
Build du matin, chagrin.
*
Observation d’Halpern
La tendance des programmeurs à se tromper, qu’ils partagent avec les autres êtres humains, a souvent été traitée comme une bizarrerie relevant de l’adolescence de la programmation, qui (comme l’acné) disparaîtrait avec la force de l’âge.
Il fut prouvé que c’était faux.
*
Huitième Loi de la Programmation informatique
Permettez aux programmeurs de programmer en anglais, et vous découvrirez qu’ils ne savent pas écrire en anglais.
*
Loi de l’Inertie de la Programmation de Dijkstra
Si vous ne savez pas ce que votre programme est censé faire, vous feriez bien de ne pas commencer à l’écrire.
*
Loi d’Incomplétude
Un programme n’est jamais fini, on arrête juste d’y travailler.
*
Inégalité de Von Neumann
Tout programme non trivial contient au moins un bug.
Corollaire :
Une condition suffisante pour qu’un programme soit trivial est l’absence de bogue.
Corollaire étendu :
Le seul programme garanti sans bug est celui qui ne comporte aucune instruction.
Ajout de Microsoft au Corollaire étendu :
Windows est un programme très long.
*
Loi de la Multiplication inévitable
Dans un programme informatique, le nombre de bugs est proportionnel à la factorielle du nombre d’instructions écrites.
*
Remarques du Développeur de Cavey
1. Dire d’un programme qu’il est bogué c’est exprimer un pléonasme.
2. Il n’y a jamais de bugs dans les programmes que j’écris : juste des caractéristiques non documentées.
*
Répartition de Werda
Il y a trois types de programmes :
- ceux avec des bugs que vous connaissez,
- ceux avec des bugs que vous ne connaissez pas,
- ceux avec les deux.
*
Loi du Bug anticommercial
Installer la dernière version d’un logiciel sur une machine critique (démonstration commerciale notamment) est le meilleur moyen d’y révéler un bug majeur et intolérable.
Corollaire :
Il n’apparaît que sur cette machine et pas sur les autres.
*
Lois de l’Archivage de Codes Sources
Énoncé faible :
Plus la nécessité de revenir en arrière dans le développement d’un logiciel (à cause de fonctions modifiées devenues buggées notamment) est criante, plus la dernière sauvegarde de sûreté est ancienne et périmée.
Énoncé fort :
Oublier d’archiver régulièrement ses données ou son code entraîne automatiquement
- que les modifications dans un premier temps seront longues, pénibles mais parfaites,
- puis entraîneront une catastrophe imposant un retour en arrière, ce qui provoquera la perte des dites modifications.
Premier Corollaire :
Les modifications perdues en revenant à une trop vieille version sont celles que votre supérieur avait apportées.
Second Corollaire :
Si vous cherchez à reconstituer certaines des fonctionnalités perdues, vous en oublierez certaines ; de plus vous obtiendrez ainsi des incompatibilités subtiles avec les logiciels développés en parallèle (incompatibilités qui attendront les clients pour apparaître).
*
Malédiction de Source Safe
Un logiciel destiné à préserver vos sources ira jusqu’à vous en interdire totalement l’accès.
*
Abomination de Felber
Quand, après bien des frayeurs, un logiciel fonctionne enfin, le simple fait de répondre « Oui » à un amical « Ça marche ? » fait planter la machine.
*
La Loi de Linus selon Raymond
Étant donnés suffisamment d’observateurs, tous les bogues sautent aux yeux.
*
Loi de Génération bugesque
L’éditeur de liens est amplement suffisant pour générer des bugs, ne vous fatiguez pas à les écrire vous-même.
*
Loi de Derouet
Le bug n’est pas l’ennemi du logiciel, c’est son compagnon de route.
*
Antigarantie de Boué
Un programme sans bug est un programme qui n’a pas été suffisament testé.
*
Loi de Pierce
Lors de chaque test de programme sur un nouveau système, la machine va toujours mal interpréter, mal afficher, mal imprimer, ou encore n’évaluera pas des sous-routines mathématiques, et tout ça dès le premier test.
*
Loi du Bug tardif
Plus un bug est découvert tard dans la journée,
plus il est incompréhensible et doit être vite corrigé.
*
Loi du Bug de Cinq heures moins Dix
(Implémentation de Courtois de la Loi du Bug tardif)
Un bug critique en production se produira dix minutes avant votre heure prévue de départ.
Premier Corollaire : C’est un jour où vous vouliez partir tôt.
Second Corollaire : Impossible de remettre au lendemain, il y a des gens qui travaillent tard ou le week-end.
Troisième Corollaire : Le collègue responsable du programme buggé est, lui, parti depuis cinq minutes.
Quatrième Corollaire : C’est un programme que vous ne connaissez pas du tout, à la logique tordue, aux spécifications absentes (ou dangereusement floues), codé avec les pieds par un consultant débutant qui a quitté la boîte il y a des années.
Cinquième Corollaire : Vous n’avez absolument pas l’état d’esprit requis à un débogage d’urgence (fatigue, trop chaud, retard à un rendez-vous...)
*
Odyssée du Bug de perf’
Soit un bête problème problème de performance, certes gênant, sur un outil informatique.
Forcément, les utilisateurs, habitués, résignés ou léthargiques, ne remonteront pas le problème (pourtant vous êtes là pour ça).
Forcément, ce genre de bug a la fâcheuse tendance à devenir critique les jours de « bourre » (le reste du temps ils ont le temps).
Forcément, le (la) nouvel(le) utilisateur(trice) qui remontera le problème ne dira pas que c’est général.
Forcément cette personne est au mieux avec son chef (au point de faire courir des ragots) ; lequel chef peut compter sur l’appui de son chef à lui, qui est hiérarchiquement plus haut que votre chef à vous.
Forcément le problème sera remonté au mauvais service, et imputé à l’ordinateur personnel de l’utilisateur (trice), tout récent, que l’intolérable pression hiérarchique forcera à changer alors qu’il est presque évident que le problème est au niveau du serveur.
Heureusement, l’excellente communication au sein du service entre personnes éloignées de quelques mètres permettra au problème d’arriver en moins de dix jours aux oreilles de personnes qui sauront en deviner et réparer la source, non sans se faire traiter de tous les noms au passage.
*
N’oubliez pas de vérifier que les routines et programmes de test ne sont pas buggées.
Corollaire :
Quand un compilateur accepte un programme sans erreur du premier coup, le programme ne fournira pas le résultat attendu.
*
Loi des Compilateurs de Conway
Si vous désignez N personnes pour écrire un compilateur, vous obtiendrez un compilateur à N-1 passes.
*
Loi d’Osborn
Variables won’t ;
constants aren’t.
*
Il y aura toujours un écart incompréhensible mais réel et subtil entre les objets réellement manipulés (fonctions basées d’une base de données par exemple) et ceux que vous avez écrits (scripts d’installation).
*
Quatrième Postulat de la Programmation de Peck
Le paramètre le plus vital dans tout sous-programme a la plus grande chance d’être oublié dans la séquence d’appel.
*
Conseil de Steinback
Ne testez jamais une erreur que vous ne savez pas gérer.
*
Loi de Récursivité d’Heller
Itérer est humain, récurser est divin.
*
Inégalité de Grabel
2 n’est pas égal à 3, même pour de grandes valeurs de 2 ou de petites valeurs de 3.
*
Loi de l’Entomologie Cybernétique de Lubarsky
There’s always one more bug.
*
Septième Loi de Gilb de la Non-Fiabilité
(Frontière de Gates)
Il existe une quantité infinie d’erreurs non décelables, alors que le nombre des erreurs décelables est, par définition, limité.
*
Loi de Belleville
La meilleure protection d’un système contre les mauvaises manipulations est l’absence totale de fiabilité, qui mène à un arrêt total de son utilisation.
Exception contemporaine :
Cependant, le manager au-dessus de l’utilisateur ne voudra pas comprendre cela et exigera qu’on se serve de l’outil, puis se plaindra que le travail est mal fait, puis s’étonnera que le travail soit fait deux fois (une fois avec l’outil, une fois bien à la main).
*
Ordre du Mérite de Coste
Le mérite de la résolution d’un problème revient au programmeur, à l’analyste et à l’auteur du problème.
L’échec ou l’erreur incombent à l’ordinateur.
*
Loi de Sorengo
Si vous êtes en passe de résoudre un problème technique, un autre surviendra avant.
*
Huitième Loi de Gilb de la Non-Fiabilité
Tous les programmes réels contiennent des erreurs jusqu’à preuve du contraire - ce qui est impossible.
*
Neuvième Loi de Gilb
L’investissement dans la fiabilité augmentera jusqu’à dépasser le coût de erreurs, ou jusqu’à ce que ce quelqu’un insiste pour qu’un travail utile soit fait.
*
Première Loi de Scott
Peu importe où est l’erreur, elle aura l’air correcte.
*
Peu importe où est l’erreur, quelqu’un savait qu’il y en aurait une.
*
Loi du Débogueur du Bogue du Voisin
Si vous demandez à un collègue son avis sur un bug sur lequel vous séchez depuis trois jours, il le résoudra en trois secondes.
*
Loi des Bugs en Cascade
Résoudre un bug rend apparent une dizaine d’autres bugs qu’il masquait.
*
Seconde Loi de Scott
Toute erreur détectée et corrigée a déjà été corrigée précédemment.
*
Fausse Joie du Message d’Erreur
Faire disparaître un message d’erreur est une utopie.
Vous n’avez simplement pas encore trouvé celui qui l’a remplacé.
*
Première Loi de l’Oracle pas clair
À deux numéros d’erreur différents ne correspondent pas forcément deux messages d’erreurs différents.
*
Deuxième Loi de l’Oracle pas clair
Si un message d’erreur porte le numéro 40035, la liste des erreurs dans l’aide du logiciel énumérera celles de 10000 à 30000 puis au-delà de 90000.
Correction : Si vous découvrez qu’il existe une autre liste de messages, qui recoupe la précédente et qui contient le message recherché, ce ne sera qu’après avoir sacrifié des heures à résoudre le problème.
*
Neuvième Postulat de la Programmation de Peck
Si plus d’une personne a programmé une routine buggée, ce ne sera la faute de personne.
*
Loi du Débogage de Littlewood-Strigini
Nos études ont montré que la probabilité qu’un programme corrigé fonctionne comme avant la correction est seulement de cinquante pour cent.
*
Loi de Stack Trace
L’Exception surgit TOUJOURS hors des try {} catch().
*
Loi du Débogage de PoV
Des tests lents et méthodiques vous feront parvenir à un point où vous pourrez localiser le bug, ou devenir fou.
Peut-être les deux.
*
Premier Postulat de Troutman
Les jurons sont le seul langage connu de tous les programmeurs.
*
Second Postulat de Troutman
La plus grave erreur d’un programme n’est jamais découverte avant que le produit soit en vente depuis 6 mois.
*
Cinquième Postulat de Troutman
Si le produit a été conçu pour rejeter toute entrée invalide, alors un crétin ingénieux découvrira une méthode pour rentrer quand même des données invalides.
*
La seule différence entre un idiot et un criminel qui attaque un système est que l’idiot attaque de façon impévisible et sur un plus large front.
*
Lois du Débogueur de Courtois
1) Étant donné un programme à déboguer, il est illusoire de penser pouvoir le déboguer complètement.
2) Il est encore plus illusoire de penser le déboguer « assez pour un utilisateur normal non vicieux » :
soit l’utilisateur est informaticien et poussera le soft dans ses derniers retranchements,
soit il ne l’est pas et aura un comportement totalement imprévisible.
*
Loi du Développeur informatique
Les utilisateurs ne savent jamais ce qu’ils veulent, mais ils savent quand votre programme ne le leur donne pas.
*
Sixième Postulat de Troutman
Si le système de test fonctionne parfaitement, tous les autres systèmes auront des problèmes.
*
Loi du Développeur d’Heurtel
Les applications ne fonctionnent que sur les PC des développeurs.
Remarque : C’est déjà pas mal, non ?
*
Effet de Bonaldi-Felber
Si vous vous ridiculisez devant un client à cause d’un bizarre bug de votre logiciel, vous constaterez plus tard que vous avez déjà lue la solution dans les groupes de discussion autrefois, et que vous l’avez oubliée.
*
Automatisme de Courtois-Baracchini
C’est quand vous vous attaquez avec fougue à une liste longue comme le bras de bugs à corriger impérativement pour le soir, qu’un collègue testeur-utilisateur du logiciel vous demande de corriger sur-le-champ une aberration qu’il vient de découvrir et qui le bloque totalement dans son travail.
*
Automatisme de Courtois-Dauché
Un excellent moyen de trouver de nouveaux bugs ou lacunes majeures d’un logiciel est de décréter qu’il est terminé et qu’on n’y touchera plus avant la livraison au client.
*
Cauchemar informatique de la Modification de dernière Minute
(Adaptation de la Loi du Client d’Hurbain)
Une modification que le client suppose prendre cinq petites minutes (ignorant déjà le temps des tests, de la mise à jour de la documentation, et de la mise en production) nécessitera en réalité deux jours de décorticage d’un code pondu à la va-vite par un sous-traitant débutant et/ou débordé et/ou négligent et/ou qui aurait dû choisir un autre métier, et la correction de deux bugs majeurs préexistants, mais ignorés et dévoilés par cette modification.
Et ce, d’autant plus que la modification semble anodine, et que vous êtes par ailleurs débordé.
*
Identification de Kulawiec
Tout bogue suffisamment avancé ne peut être distingué d’une fonction.
*
Théorème bogué
Tout bogue que vous trouvez est le dernier.
*
Loi de Sysiphe
Du mauvais code n’a pas besoin d’être commenté ou corrigé, mais réécrit.
*
Contradiction de Shryer
Si le code et les commentaires se contredisent, les deux sont probablement faux.
*
Loi d’Eagleson
Un code que vous avez écrit et que vous n’avez pas regardé depuis plus de six mois aurait très bien pu être écrit par quelqu’un d’autre.
Remarque : Eagleson est optimiste, le vrai nombre est plus proche de trois semaines.
Remarque à la remarque : En C++ c’est trois jours.
Extension de Vasselot : Cette loi est extensible à n’importe quel language.
*
Règle de l’Adéquation ludique de Lancelot
Le langage C a ceci de particulier que lorsque vous tentez de développer un jeu de football, à la compilation, vous obtenez un jeu de tennis.
Corollaire : Malgré tout, les règles du jeu sont généralement conservées.
*
Loi numérique
Si vous n’y arrivez pas du premier coup, appelez ça version 1.0
*
Loi d’Adéquation
Il vaut mieux changer le cahier des charges pour l’adapter au programme que vice-versa.
*
Seconde loi de Weinberg
Si les architectes travaillaient de la manière dont les programmeurs programment, un seul pic-vert détruirait la civilisation.
*
Loi du Grand Bêta
Un logiciel finalisé est une version bêta qui s’ignore.
*
Loi bêta de Flash
La version définitive du logiciel Micro$oft que vous venez de payer est en fait une nouvelle version bêta.
Vous trouverez bien assez de bugs pour vous en convaincre.
Nouveauté Micro$oft 98 : En plus, même si c’est une bêta, vous l’aurez payée !
*
Seconde Loi de Golub
L’un des avantages de fixer des objectifs vagues à un projet, c’est que vous n’aurez pas de difficultés à estimer les dépenses correspondantes.
*
Loi du Projet auto-buggant
Ne placez pas une base destinée au suivi des incidents/bugs/tickets/observations d’un projet dans la même base de données ou le même serveur que ledit projet.
*
Huitième Loi de Golub
Un projet mal planifié prend trois fois plus de temps que prévu,
alors qu’un projet soigneusement planifié ne prend que deux fois plus de temps.
*
Onzième Loi de Golub
Les équipes de projet détestent les comptes-rendus hebdomadaires d’avancement des travaux, parce que ceux-ci mettent trop vivement en lumière l’absence de leur progrès.
*
Quatrième Loi de Gilb de la Non-Fiabilité
Un système tendra à grossir dans le sens de la complexité plutôt que de la simplification, jusqu’à ce que l’instabilité résultante devienne intolérable.
*
Cinquième Loi de Gilb de la Non-Fiabilité
Les systèmes auto-correcteurs tendent à avoir une complexité en proportion de la non-fiabilité inhérente au système qui les utilisent.
*
Cinquième et Septième Loi de la Programmation informatique
(Lois de Croissance)
La taille d’un programme grandira jusqu’à occuper tout l’espace mémoire disponible.
La complexité d’un programme grandit jusqu’à ce que son concepteur n’y comprenne plus rien.
*
Mythe du Code Portable sur toutes les Machines
Il existe.
*
Précaution de Brandwein
Méfiez-vous des programmeurs qui portent des tournevis.
*
Quatrème Loi de la Programmation informatique
Tout programme inutile doit être documenté.
Corollaire : Quand un logiciel est inutile, on y forme les gens.
*
Loi de l’Emmerdement maximum du User
Plus petite la modification demandée par l’utilisateur,
plus gros le boulot nécessaire.
Corollaire : Finalement, il n’en aura pas besoin.
*
Loi Métaphysique des Programmeurs
La vie serait plus facile si on en avait le code source.
*
Lois du Développement Différentiel en Informatique d’Entreprise
1) Avec le temps, un environnement de test diverge inévitablement de celui de production.
2) Il est utopique (et bugogène) d’espérer avoir un environnement de test en synchronisation permanente ou presque avec celui de production : au mieux il sera en retard de plusieurs fois le temps caractéristique d’évolution du système réel ; au pire il sera totalement non-fonctionnel.
3) Aucune des données ’foireuses’ qui mènent à des plantages de programmes en production n’est présente en environnement de test.
4) Aucune des données ’réelles’ qui permettent d’au moins valider le comportement ’normal’ non plus d’ailleurs.
Première Exception : Si ces données sont là, le but du programme sera évidemment de les modifier ; on ne pensera à une sauvegarde desdites données qu’après leur destruction.
Seconde Exception : Un autre développeur travaillant aussi dessus les corrompra pour vous.
5) Tout environnement de pré-production destinée aux tests ultimes, si par bonheur il existe, sera soit trop fréquemment rafraîchi pour être utile, soit trop strictement tenu pour éviter toute dérive, soit pas assez tenu et devenu un second environnement de test aussi corrompu que le premier.
6) Si le système est assez simple pour que chaque intervenant ait son système de test personnel, il passera à côté de tous les problèmes d’interaction et de verrouillage mutuel.
7) Si le système est assez simple pour être regénéré rapidement et souvent, alors les phénomènes de décrépitude de ce système seront la première source de bugs en production.
8) Le paramétrage et donc les performances du système de test n’ont rien à voir avec celles de celui de production. De préférence dans des sens variants selon les applications.
Corollaire d’Oracle : Les volumétries des objets sont assez différentes pour empêcher toute hypothèse sur ce qui se passera en production.
9) Si un système est assez simple pour ne pas se voir appliquer les lois précédentes, ce n’est pas un système d’entreprise réel.
*
Loi du Test Impossible
Tout environnement de test aura tendance à devenir indisponible
quand le projet prend du retard et que la date limite approche.
*
Tout environennement de validation et test pour une migration d’un logiciel lourd et critique sera en retard d’une troisième décimale de version par rapportà la version réellement en production.
*
Loi de la Décommission
Tout système éprouvé dont la désactivation est prévue à moyen terme marquera sa désapprobation en déconnant grave de manière répétée.
Corollaire: Le remplaçant n’est pas prêt.
Exception au Corollaire: Si le remplaçant est prêt, il sera mis en production plus tôt que prévu, et soit l’intégration précipitée sera un cauchemar, soit vous constaterez que non, il n’est pas prêt.
Sous-traitance informatique (Off-shore)
Loi du Développement Offshore partiel
Tout programme pensé, développé, optimisé avec soin reviendra dans un état bancal et instable d’une modification par un sous-traitant du tiers-monde.
Corollaire : Vous n’aurez pas le temps de corriger, juste de sauver les
meubles.
*
Constatation fondamentale de Courtois
Ce n’est pas parce qu’un sous-traitant a livré un programme apparemment cohérent qu’il a compris quoi que ce soit à la problématique.
Corollaire : Évidemment, il n’a rien testé.
*
Loi de Philippe des Spécifications
Si le logiciel fraîchement livré semble fonctionner, on constatera dans un deuxième temps qu’il ne respecte pas toutes les spécifications ; le sous-traitant livre dans les délais un programme en fait non terminé.
Corollaire : Le seul cas où toutes les spécifications ont été suivies aveuglément sont celles où une interprétation critique eût été nécessaire, notamment quand elles ne sont pas à jour et ont fait croire à la suppression de la moitié des fonctionnalités.
*
Loi informatique du Service d’Éditeur
Ce n’est pas parce que vous confiez le déploiement, l’intégration, la gestion d’un logiciel à son éditeur même que le travail sera fait par des gens connaissant bien le produit.
*
Métrique de l’Off-shore
Vous auriez pris moins de temps à le faire vous-même qu’à relever toutes les aberrations commises.
Corollaire : Contractuellement, vous n’avez même pas le droit de corriger vous-même.
*
Loi du Développement logiciel sous-traité
Plus vos standards de développement sont élevés,
plus le sous-traitant est renommé,
plus scandaleux le résultat.
Corollaire : Techniquement, ça marche. Ce sera juste un cauchemar à maintenir.
*
Dilemme de Toussaint
Vous n’avez contractuellement pas le droit de modifier ce que livrent vos sous-traitants, qui sont responsables des corrections.
Vous n’avez réalistement pas le temps d’attendre qu’ils corrigent leurs erreurs de débutant, si jamais ils en sont capables.
Corollaire : Pour votre chef, ça doit marcher, dans les délais, et en respectant le contrat.
Bug de l'An 2000
Loi médiatique bimillénaire
Les médias ne connaissent qu’un bug, celui de l’An 2000.
L’informaticien rencontre tous les jours de nouveaux bugs dont les journaux ne parlent pas.
*
Troisième Loi de Bernard et Michel
C’est toujours quand on veut passer l’an 2000 que la Tour Eiffel tombe en panne
*
Loi de la fausse Joie
Si tout va bien le 1
er janvier 2000, n’oubliez pas que les gens ne retournent au bureau que le 3.
*
Loi des 2000 Bugs de Daury
Si votre système informatique résiste au passage à l’an 2000, alors le 29 février lui sera fatal.
Corollaire :
Les désastres occasionnés par le 29 février seront bien plus important que ceux prévus, même dans la pire des hypothèses.
Bureautique et logiciels
Loi de Répression de l’Anarchie de Coste
L’ordinateur permet des classements parfaits : il évite ainsi d’ajouter le désordre à l’incompétence.
*
Loi Anti-révolutionnaire de Coste
La révolution informatique n’a pas entraîné jusqu’à présent l’envahissement des bureaux par des compagnies de C.R.S.,
mais seulement par des tonnes de papier.
*
Loi des Marges d’Hurbain
C’est à l’impression de la dernière page du rapport de stage qu’on se rend compte que non, décidément, la marge droite et la marge gauche ne sont pas égales.
Déduction : Word ne connait pas le sens du mot « égal ».
*
Constatation de Bardot
Plus un programme est important et donc utilisé,
et plus il y a des bugs que l’on ne peut résoudre.
*
Loi du Shareware customisé
Le seul programme connu qui comporte LA fonction tordue et vitale que vous recherchez depuis des années est d’une part, totalement nul , par ailleurs, et d’autre part, totalement incompatible avec les autres applications du domaine.
*
Loi de Jakubowicz
L’intérêt porté à un logiciel est inversement proportionnel à votre capacité à repérer sa non-gratuité.
Corollaire :
Ce sont toujours les meilleurs logiciels, et qui vous rappellent avec le plus d’insistance qu’il faut payer la licence, qui sont le plus dur à cracker.
*
Loi de la License de Shareware
Vous n’aurez besoin d’un shareware que jusqu’au moment où vous en achèterez la license.
*
Loi du « Super Shareware de la Mort qui tue »
Après un long téléchargement interrompu à cinq reprises, une longue et pénible installation, après que tout semble marcher, vous vous apercevez qu’il nécessite une DLL de runtime à télécharger séparément (surtout si vous installez le programme sur un ordinateur qui n’a pas accès à Internet)
*
Troisième Loi de la Programmation informatique
Tout programme utile sera remplacé par un autre moins performant.
*
Loi Info-documentaire de Prigent
L’utilisation d’une documentation imprimée est inversement proportionnelle à la place qu’elle occupe.
Corollaire : Si une impression est malgré tout utile, elle sera perdue.
*
Loi de dBase
Le prix d’un programme est inversement proportionnel à son ergonomie.
*
Sixième Loi de la Programmation informatique
La valeur d’un programme est proportionnel au poids de ses fichiers de sortie.
*
Loi du Prix par Bit de Space Invaders
Le prix d’une cartouche de jeu est directement proportionnel au nombre de bits de la console qui la supporte.
*
Loi de Lourdeur
Le prix d’un programme sera proportionnel à la lourdeur de ce qu’il donne en sortie.
*
Loi Info-orthographique de Vivier
L’utilisation d’un correcteur orthographique permet par la suite au lecteur de se concentrer sur les aberrations grammaticales sans être perturbé par les défaillances orthographiques.
*
Loi de l’Émulateur PC sur Mac
...Ou comment avoir tous les inconvénients du PC sans en avoir les avantages.
*
Loi de Iomega
Ils ont pensé à tous les problèmes dans le mode d’emploi, sauf à la panne ou à l’erreur que vous rencontrerez.
Imprimantes
Lois de HP-LPT1
Tout câble d’imprimante a d’autant plus de chances d’être défectueux qu’il est long.
Si, à titre de vérification, on veut emprunter celui d’un autre ordinateur, les vis qui fixent ce câble au port parallèle viendront avec.
*
Loi de Miod des câbles SCSI
Si vous achetez du matériel SCSI externe pour un ordinateur disposant déjà d’une imprimante, alors on vous fournira un câble SCSI2 (même connecteur sur le pécé que le câble d’imprimante).
Et la probabilité que vous branchiez l’imprimante sur la carte SCSI et le périphérique SCSI sur le port imprimante (ce qui fait fumer au
moins une carte) est proportionnelle au prix du matériel.
*
Loi de l’Impression
Imprimer un document sans le sauvegarder mène à un plantage de l’imprimante.
Conséquence :
Si vous avez fermé le document, il faudra le refaire ;
si vous ne l’avez pas fermé, le système plantera avant que vous puissiez.
Ordinateurs de poche
Première Loi de Shelton des Calculatrices de Poche
Les batteries expireront au moment le plus crucial du problème le plus complexe.
*
Troisième Loi de Shelton des Calculatrices de Poche
La réponse finale excédera la magnitude ou la précision (ou les deux) de la calculatrice.
*
Quatrième Loi de Shelton des Calculatrices de Poche
Il n’y a jamais assez de mémoire pour résoudre le problème.
*
Ou bien aucun vêtement n’a de poche assez grande pour la contenir.
*
Dans le cas contraire, les touches sont trop petites.
*
Cinquième Loi de Shelton des Calculatrices de Poche
L’utilisateur oubliera les mathématiques en proportion de la complexité de sa machine.
Multimédia
Loi du Décompresseur vidéo
Vous pensiez tous les avoir ? Et bien non...
Addendum :
Si vous avez l’image, vous n’aurez pas le son, et inversement.
*
Apport de Miod à la Vision des Ordinateurs par Hollywood
Si jamais un ordinateur tombe en panne ou devient fou dans un film,
alors soit c’est un très vieux modèle d’une marque disparue,
soit c’est un modèle récent d’une marque contrôlée par le(s) méchant(s),
soit on en ignore la marque...
Jamais de dénigrement !
*
Loi Virale du 4 Juillet
Le système informatique d’un astronef gros comme la lune peut être contaminé par un petit virus informatique d’une civilisation en retard de plusieurs milliers d’années.
*
Lois du Silence de Coste
Lorsque l’ordinateur aura appris à chanter, il est à craindre qu’une vague de chômage ne déferle sur le monde artistique français : quel repos pour notre ouïe...
Vivement la synthèse vocale : combien de petits chanteurs trouveront enfin le moyen de chanter juste et en mesure à défaut de chaleur, de sensibilité et d’amplitude ?
Me laisser un mot
Retour à la page principale des Lois de Murphy.
Retour à la page principale.