Le chef de projet demande une confiance totale à chaque fois qu'il engage du code

Comment répondre à sa question dans ce cas, sans paraître incompétent ? Honnêtement, je n'ai jamais confiance à 100% sur le terrain, mais j'ai confiance dans mes méthodes de test. Et, en tant que développeur, je sais aussi qu'il n'est pas rare que des bogues inattendus surgissent plus tard de ces changements fondamentaux.

Le chef de projet ne comprend pas assez bien les logiciels, et certainement pas assez bien les tests. Il a peut-être besoin d'être éduqué.

Si vous aviez un service d'assurance qualité professionnel, je vous dirais de demander l'aide du responsable de l'assurance qualité pour expliquer à ce chef de projet la nature du logiciel, la nature des bogues et la nature des tests. Je lui demanderais d'expliquer pourquoi il n'est tout simplement pas possible de tester toutes les conditions, et comment le fait de publier ou non une version est une activité commerciale qui s'appuie sur les résultats des tests, mais jamais sur des informations parfaites. Vous pouvez vous procurer un exemplaire de l'excellent livre de Gerald Weinberg “* Perfect Software and other illusions about testing **”. Dans le chapitre 3 (“Pourquoi ne pas tout tester”), Weinberg a une section intitulée “Il existe un nombre infini de tests possibles”

Il parle d'une porte dérobée placée dans un programme hautement sécurisé par laquelle la protection ordinaire par mot de passe pourrait être contournée en tapant W suivi de trois espaces, puis M suivi de trois espaces, puis J suivi d'exactement 168 autres frappes sans utiliser une seule fois la lettre L.

Puis il écrit : “Avez-vous compris le point maintenant ? Si vous n'avez pas deviné que le nombre de tests nécessaires pour tester exhaustivement un logiciel est infini, ou du moins "un nombre supérieur à celui que je pourrais exécuter au cours de ma vie”, vous n'avez pas compris le sens de ce chapitre. Maintenant, vous le comprenez"

Expliquez à votre chef de projet que chaque jour de tests supplémentaires améliorera quelque peu votre confiance dans votre code, mais qu'elle ne pourra jamais atteindre 100%. Dites-lui que vous seriez heureux de continuer à tester au détriment de votre autre travail productif. Demandez-lui ensuite combien de jours supplémentaires il aimerait que vous consacriez aux tests et lesquels de vos autres travaux devraient être reportés.

Si votre chef de projet ne comprend toujours pas, et que vous vous sentez un peu désinvolte, demandez-lui s'il est sûr à 100% que chaque estimation qu'il publie est exactement correcte et que les délais ne seront jamais dépassés. Demandez-lui s'il est sûr à 100 % qu'aucun courriel qu'il écrit de maintenant à jamais ne comportera de coquille. Demandez-lui s'il est sûr à 100 % qu'il ne fera jamais d'erreur - maintenant et à l'avenir.

Patron: Êtes-vous sûr à 100% que cette correction ne cassera aucune fonctionnalité existante ou n'aura pas d'effets négatifs sur l'expérience de l'utilisateur ?

Me: Non. Comme nous n'avons pas de suite de tests de couverture à 100%, il n'y a aucun moyen de vérifier que tout changement de code évitera la casse de l'application ou des effets négatifs. Cependant, j'ai effectué les actions suivantes pour m'assurer qu'il est peu probable que cela se produise de manière involontaire : J'ai limité la portée de la modification au seul module concerné. J'ai lu et mis à jour la documentation en conséquence. J'ai effectué les tests unitaires pour ce module et les modules concernés. J'ai créé des tests unitaires pour vérifier les nouvelles fonctionnalités ajoutées et les tests obsolètes qui ne sont plus pertinents en raison de la modification. En fait, j'ai déjà atteint le point où les rendements diminuent. Je peux passer encore 5 heures pour vous donner une autre assurance de 0,1%, mais il y a déjà tellement peu de chances que cet effort ne soit pas justifié. Cependant, vous êtes en charge du projet et du calendrier, alors faites-moi savoir combien de temps encore je devrais consacrer à cette fonction.

Maintenant, la balle est dans son camp. S'il veut vraiment que je fasse passer mon estimation personnelle de, disons, 95% sûr à 95,1% sûr pour quelques heures de travail supplémentaires, alors hé - je peux le faire.

S'il continue à être odieux à ce sujet, j'aurai une conversation par e-mail avec lui et le “propriétaire” du projet au sujet de cette exigence “testée à 100%”, et des ressources que je crois nécessaires pour y répondre.

En tant que développeur, vous êtes UNIT à tester les changements apportés à votre code. A mon avis (en tant que développeur), c'est-à-dire pour vérifier qu'il n'y a pas d'erreurs évidentes, tout se compile, toutes les erreurs sont piégées. Vous n'avez aucun moyen de savoir quels scénarios seront rencontrés une fois le code mis en ligne (mauvaises données, entrée inattendue, changement de logiciel client, la liste est infinie)

Pour être sûr à 100 % qu'un changement n'affectera rien, il vous faudrait un environnement de test qui reflète EXACTEMENT l'environnement réel (données, matériel, autorisations, connectivité) et une suite de scripts de test qui couvrent chaque scénario. C'est, comme on le sait, un environnement virtuellement impossible à créer pour diverses raisons

S'il s'attend à une confiance à 100%, il doit alors fournir l'environnement et la main d'œuvre pour soutenir ses attentes

C'est un peu comme quand les chefs de projet et les clients demandent des choses pour être à l'épreuve du futur !

On dirait qu'il est tombé dans une mauvaise habitude. Il pose une question qu'il sait, à un certain niveau, être idiote. Mais il y a un élément compulsif. Je pense qu'il agit sur une anxiété sous-jacente, et le fait de poser une question déraisonnable lui donne l'impression de mieux contrôler la situation.

Dans ce genre de situations, j'essaie de diffuser la dynamique en étant confiant et en injectant un peu d'humour. Si vous comprenez que sa question ne vient pas du raisonnement, mais de l'anxiété, alors vous pouvez mieux l'aborder indirectement que directement.

Dans ce genre de situations, j'apaise généralement les craintes de la direction en présentant toutes les mesures que j'ai prises pour assurer la qualité. Après tout, c'est le client, et il doit savoir que vos priorités sont en accord avec les siennes. Regardez ces tests unitaires. Regardez ce suivi. Regardez comment le code est structuré pour que les changements restent locaux et modulaires. etc. Si vous transmettez un sentiment de confiance et de contrôle, cela apaisera son anxiété et vous pourrez probablement avoir une conversation plus rationnelle.

C'est là que l'art de ce métier entre en jeu. Pas seulement “ça marche”, mais le client se sent bien.

Mais en fin de compte, c'est une relation d'affaires. Si le contrat est confortable et rentable pour vous, alors il vaut la peine de supporter cette bizarrerie. On dirait qu'il n'est pas si sérieux que ça, mais qu'il est plutôt persistant. Comme je l'ai dit, il a développé une fâcheuse habitude. S'il commence à réagir négativement et que le ton devient plus hostile, l'équilibre de l'accord commercial peut alors faire que cela ne vaut pas la peine pour vous. Mais d'après votre brève description, il me semble que vous pouvez encore gérer la relation efficacement.

Beaucoup de gens ont décrit cela comme un problème d'éducation, et je ne dis pas qu'ils ont tort.

Il est également possible que ce soit un problème politique. Ce que la question pourrait en fait signifier, c'est que le chef de projet veut être exonéré de toute responsabilité pour toute erreur. Il reçoit une déclaration sous serment de votre part sur laquelle il estime pouvoir se fier “raisonnablement”, donc si quelque chose tourne mal, il dit qu'il a fait tout ce qu'il a pu pour l'éviter mais que vous avez échoué.

Ce n'est pas de la bonne gestion et ce n'est pas non plus garanti à 100% de le mettre au clair si des problèmes surviennent.

J'admets que c'est de la spéculation de ma part, mais les exercices de couverture des fesses ne sont pas du tout rares dans la vie professionnelle et vous devez y faire face. Si cela semble vrai, alors ce que vous devez faire pour résoudre le problème n'est pas seulement d'apprendre au manager qu'une confiance à 100% est impossible. Vous devez également le convaincre qu'un bogue n'est pas un désastre - pour lui personnellement ou pour l'entreprise.

Cela peut signifier, par exemple, fournir des exemples de bogues traités à un coût raisonnable et sans qu'aucun reproche ne soit fait. Cela peut signifier qu'il faut examiner sa propre culture d'entreprise, pour voir si quelqu'un d'autre dans l'entreprise se prépare à lui faire porter injustement le chapeau si quelque chose tourne mal. Cela pourrait également signifier la mise en place de procédures pour traiter les futurs bogues aussi rapidement et à moindre coût que possible. Si l'entreprise avait vraiment confiance à 100 % dans le code, de telles procédures seraient inutiles car elle serait prête à parier arbitrairement de grosses sommes d'argent sur l'absence de futurs bugs !

Comme sanction ultime, s'il (l'employeur) vous demande (à l'entrepreneur) de lui vendre une garantie que vous ne pouvez pas donner sur votre travail, et que rien ne le fera changer d'avis sur ce point, alors tout ce que vous pouvez faire est d'indiquer clairement que vous n'êtes pas en mesure de fournir cette garantie, et qu'il est le bienvenu pour employer quelqu'un d'autre s'il pense qu'il y a quelqu'un qui le peut. Bien sûr, c'est un long chemin à parcourir, mais autant connaître votre BATNA avant de commencer.

**Même avec toutes sortes de tests possibles (tests unitaires, intégration, composants, système, manuel, interface utilisateur, fuzz, sécurité, pénétration…), on ne peut jamais être sûr à 100% qu'un commit ne casse pas un programme. Ceci est dû à un problème d'arrêt . Un extrait pertinent de la Wikipédia suit ci-dessous :

Dans la théorie de la calculabilité, le problème d'arrêt peut être formulé comme suit : “Étant donné la description d'un programme informatique arbitraire, décider si le programme finit de tourner ou continue de tourner pour toujours”. Cela équivaut au problème consistant à décider, étant donné un programme et une entrée, si le programme s'arrêtera finalement lorsqu'il sera exécuté avec cette entrée, ou s'il s'exécutera pour toujours.

Alan Turing a prouvé en 1936 qu'un algorithme général pour résoudre le problème de l'arrêt pour toutes les paires possibles de programmes-entrées ne peut pas exister. Une partie essentielle de cette preuve était une définition mathématique d'un ordinateur et d'un programme, qui est devenue connue sous le nom de machine de Turing ; le problème de l'arrêt est indécidable sur les machines de Turing.

Si votre chef de projet se soucie de la valeur et de la stabilité de la livraison prévisible, vous pouvez peut-être le convaincre de jeter un coup d'œil à SCRUM framework .

D'autres ont donné de nombreux conseils intéressants sur la façon d'interagir avec votre chef de projet. Personnellement, je vous conseille d'organiser une réunion avec votre Premier ministre et l'équipe pour discuter de vos processus. Je suis fortement en faveur de la SCRUM, donc cela serait largement lié à la SCRUM.

J'essaierais d'expliquer qu'un objectif de 100% est insaisissable. Il ne peut être atteint. Jamais. Dans l'univers entier. L'histoire a vu beaucoup d'exemples de ce genre, démo de la sortie de Windows 95 par exemple. Il y a longtemps ? Eh bien, regardez combien de builds rouges sur un serveur public de CI pour les projets open source ; connectez-vous en tant qu'invité si vous n'avez pas de compte sur ce site. Deuxièmement, je vous conseille d'adopter une pratique où vous pouvez fournir une valeur au lieu de la confiance d'un commit. Quelque chose dont les clients se soucient. De manière itérative, répétée et fiable. Maintenant, vous pouvez faire passer le point de vue de votre Premier ministre de l'assurance à 100% à quelque chose qui compte vraiment. C'est-à-dire : le logiciel est utilisé, votre produit s'améliore et l'équipe apporte de la valeur au client.

Troisièmement, il faut définir ce qui est fait. Quelque chose qu'une équipe de développement trouve. Cela peut comprendre : la documentation, la mise en œuvre, les tests, les points de contrôle de la qualité, etc. C'est très important, car vous pouvez maintenant passer de la subjectivité (c'est-à-dire “êtes-vous sûr à 100% ?”) à la objectivité (c'est-à-dire que tous les points de la définition de “fait” sont complétés).

Il y a d'autres étapes très importantes que SCRUM encourage. Mais toutes permettraient aux développeurs d'atténuer cette frustration, et leur permettraient de fournir un résultat objectivement quantifiable, par rapport à une assurance subjective.

La réponse habituelle à ce genre d'objectif est l'examen par les pairs et les tests de régression.

1) Ne rien engager dans le flux de code de production avant que non seulement l'auteur, mais aussi un ou plusieurs autres programmeurs, ne l'aient contrôlé pour s'assurer qu'il ne modifie que ce qui est nécessaire, qu'il répond à tous les critères convenus pour une bonne pratique de codage, qu'il est accompagné d'un test qui vous donne des chances décentes de détecter si une modification ultérieure casse à nouveau la logique, etc.

2) N'engagez rien dans le flux de code de production tant que TOUS les tests de régression n'ont pas été relancés et qu'il n'a pas été prouvé que le test ne casse rien. Si un échec survient pendant ce test, la modification doit être annulée jusqu'à ce qu'il puisse être clairement établi qu'elle n'est pas à l'origine du problème.

3) Testez les versions alpha et bêta tôt et souvent avec des scénarios clients réels. Les clients feront avec votre code des choses auxquelles vous ne vous attendiez pas.

Aucun de ces scénarios n'est à 100%, ni leur combinaison. Mais ils vous rapprochent considérablement. Ils nécessitent un investissement non négligeable de ressources supplémentaires. Ils ralentissent le développement par rapport à la pratique de codage “faites-le et nous le réparerons quand il sera cassé”. Mais si vous voulez vraiment un code sans bogue, reconnaître que les humains sont faillibles et mettre en place des pratiques pour aider à attraper les échecs avant qu'ils n'atteignent les clients peut valoir plus que ces coûts.

On m'a dit qu'il n'y a jamais eu de bogue signalé dans le code qu'IBM a écrit pour la NASA – parce qu'il a été examiné par des pairs et testé à mort pendant la conception, pendant le développement et avant d'être publié.

Si vous faites quelque chose de vital, cela vaut évidemment cet investissement. Si vous faites quelque chose qui est une infrastructure pour de grandes entreprises, cela vaut la peine d'investir ; vous ne voulez pas être celui dont le bogue fait tomber les processus d'affaires d'une entreprise d'un milliard de dollars.

Oui, cela rend les bons codeurs fous. Jusqu'à la première fois, cela leur sauve la vie.

La vérité est qu'il s'agit d'un mauvais test. La réalité est qu'une entreprise qui ne veut pas investir dans une équipe d'assurance qualité aura des tests médiocres. Un bon test est coûteux et prend du temps. L'entreprise a accepté le risque en n'autorisant pas le temps et l'argent.

Même une équipe d'assurance qualité ne peut pas garantir que chaque possibilité est testée parce que les chemins possibles à travers un programme complexe sont fondamentalement infinis. Cependant, elles vous permettront de vous rapprocher beaucoup plus que vous ne le faites actuellement. L'une des raisons est qu'il est impossible pour un développeur de tester correctement son propre code. Ils savent ce qu'il fait, donc ils ont tendance à concevoir des tests en fonction de ce qu'ils pensent qu'il est censé faire. Ils ratent les cas limites, ils ratent les choses stupides que les utilisateurs font et qu'un développeur ne ferait jamais parce qu'il sait comment cela fonctionne, ils interprètent parfois mal les exigences mais tous leurs tests reflètent leur interprétation originale incorrecte. Ils ratent souvent des erreurs dans l'exigence et font ce qu'on leur demande de faire et non ce qu'ils auraient dû faire (c'est la cause d'un grand nombre de bogues qui ne sont découverts qu'après que les utilisateurs réels [qui ne sont trop souvent pas consultés pour définir l'exigence] essaient d'utiliser le logiciel). Ils manquent des effets sur des parties de l'application qu'ils n'ont jamais eu de raison de travailler, en particulier sur des parties qui sont faites par des spécialistes (comme un changement de table qui a du sens pour l'application mais qui casse un processus d'importation automatisé ou un rapport)

S'il veut une meilleure qualité, il devra payer pour cela à la fois en temps et en argent. Même avec une assurance qualité complète, vous ne pouvez pas atteindre 100 %, bien que la NASA et ses sous-traitants s'en approchent certainement. Ils dépensent aussi beaucoup plus d'argent que votre entreprise. Si ce qu'il veut, c'est l'assurance qu'aucun problème ne lui causera de tort avec les clients, alors parlez-lui de votre processus de test (Montrez-lui la liste des tests que vous avez effectués), de ce qui, selon vous, pourrait être affecté et comment vous avez vérifié cela, de votre processus pour savoir comment vous pourriez inverser une mauvaise poussée et de votre processus pour enregistrer les erreurs afin que vous puissiez les voir avant que la plupart des clients ne les remarquent. Donnez-lui l'assurance que même s'il y a un problème, il peut être résolu. Parlez de l'intérêt de sortir rapidement le code (nouvelle fonctionnalité ou correctif) par rapport au temps supplémentaire qu'il faudrait pour effectuer des tests plus approfondis. Vous pouvez également lui demander de fournir le test de régression complet du système chaque fois que vous apportez une modification, car il n'est pas possible pour un développeur de tester complètement son propre travail (vous savez quelles étaient vos hypothèses, si elles ne sont pas correctes, vous ne feriez jamais de test pour cela). Assurez-vous qu'il sait qu'il devra tester chaque page de l'application et chaque chose qui pourrait être faite sur une page dans tous les ordres possibles. Oh oui, testez aussi les importations/exportations, les rapports, les travaux automatisés. Et toutes les applications connexes qui pourraient être affectées. Une fois qu'il aura essayé de tester le système en profondeur une fois, il réalisera pourquoi vous ne pouvez pas faire cette garantie.

Une autre chose à essayer est de lui dire d'emblée que non vous ne pouvez pas faire cette garantie, mais que s'il autorise X heures de test, vous pouvez vous rapprocher de cette garantie. Donnez-lui une liste détaillée des tests supplémentaires et des heures qu'il faudrait pour concevoir et exécuter chacun d'entre eux. Dites-lui quel pourcentage de confiance vous auriez après avoir exécuté tous ces tests et quel pourcentage de confiance vous avez actuellement.

D'ailleurs, dites-lui combien de temps il faudrait pour exécuter tous les tests unitaires actuels que vous avez, qu'ils soient liés à cette question ou non. Ainsi, si vous avez actuellement 1000 tests unitaires et que chacun d'entre eux prend cinq minutes à mettre en place, à exécuter et à évaluer les résultats, cela représenterait 83 heures. Demandez-lui l'autorisation d'aller de l'avant et de consacrer ce temps.

S'il est en fait en train de vous micro-gérer et de regarder par-dessus votre épaule tout au long du processus de construction du projet, il existe un moyen facile de s'assurer que vous pouvez “garantir” une confiance à 100% sans qu'il vous en parle plus tard.

Demandez-lui de l'approuver lui-même

Pour être clair, vous ne devriez pas faire cela comme une demande, mais plutôt comme une suggestion, que s'il veut vraiment un code 100% parfait, alors il devrait regarder ce que vous faites lui-même et approuver chaque changement que vous faites en cours de route. Cela ne veut pas dire qu'il doit lire le code littéralement, mais plutôt le voir en action et confirmer “oui, c'est comme ça qu'il doit agir”.

Si vous êtes le seul à tester votre propre code, ce n'est pas déraisonnable - vous êtes déjà entièrement concentré sur le projet, et s'il veut la perfection, il devrait prendre la responsabilité de s'assurer lui-même de cette perfection.

Prenez également des notes sur tout ce qu'il approuve, de sorte que plus tard, lorsqu'il y a inévitablement une rupture, vous puissiez montrer du doigt votre documentation montrant qu'il l'a approuvée. Si, pour une raison quelconque, vous pensez que cela ne se passerait pas bien (par exemple, si lui demander de faire plus de travail est quelque chose que vous savez déjà être désastreux), tout ce que vous pouvez vraiment faire est de tester autant que possible les erreurs, d'écrire dans vos rapports tout ce que vous savez fonctionner correctement, et de lui donner l'assurance que, “dans les limites de mes tests, je suis confiant à 100% dans ces changements”. Malheureusement, il se peut que vous ayez un “patron” dont la compréhension de votre travail est limitée, ce qui est toujours pénible lorsqu'on essaie d'expliquer comment la correction des erreurs est impossible à maintenir avec une confiance à 100 %. En résumé, votre meilleure chance est peut-être de faire de votre mieux, de tout enregistrer et de faire comprendre que vous faites ce que vous pouvez dans vos propres limites.

Le Premier ministre a besoin d'être éduqué et d'apprendre un peu ce que signifie écrire un logiciel. Je ne veux rien répéter de tout cela, mais j'ai une autre idée assez inhabituelle. Cette méthode est assez risquée et dépend beaucoup de votre réputation, de la qualité de vos compétences (ou plutôt de la façon dont elles sont perçues), de votre personnalité et de celle de votre Premier ministre. Je suppose que vous ne l'avez pas mal compris, et il veut vraiment dire 100% (je vois souvent des gens dire 100%, mais qui veulent vraiment dire “faites de votre mieux”)

Cela a marché pour moi une fois, et c'est la seule raison pour laquelle je le mentionne ici. Vous avez été prévenu. C'est surtout un moyen possible d'éduquer un Premier ministre si tous les autres moyens échouent.

Parfois, un Premier ministre (ou tout autre manager) ne veut tout simplement pas écouter, alors il faut bien que quelque part, vous lui fassiez taper sur un mur (ou à l'équipe) pour qu'il s'arrête un moment et réfléchisse. Dans ce scénario, cela signifie : Travaillez aussi bien que vous le pouvez, essayez de tester aussi bien que vous le pouvez. Donnez le meilleur de vous-même, puis dites “Oui, je suis sûr à 100% que ça va marcher”.

Si vous êtes extrêmement chanceux, aucun bug ne se produira jamais et tout le monde est content ; mais en réalité ce qui se passera est : il y a un bug. Qu'allez-vous faire maintenant ? Vous admettez que vous avez fait une erreur. Faites le lien avec les bugs et l'erreur d'être sûr à 100%. Les humains sont imparfaits et peuvent créer des bogues dans les logiciels. Les humains sont imparfaits et peuvent créer des bogues dans les tests. Par conséquent, les humains sont imparfaits et peuvent “créer des bugs” dans leur perception d'être sûr à 100% qu'il n'y a pas de bug.

Présentez ce puits, et 100% étanche (haha, j/k, les 100% encore). Assurez-vous qu'après tout cela, le message passé est “Je ne peux pas être sûr à 100% dans mes tests”. Si le Premier ministre ne peut pas faire le pas logique de “Ce sera pareil pour tous les développeurs”, alors tout espoir est probablement perdu…

Mais s'il vous plaît, essayez d'autres choses d'abord !

L'indicateur clé est qu'il s'agit d'un changement récent. Quelque chose (ou quelqu'un) a probablement fait vivre une mauvaise expérience à votre Premier ministre, et maintenant il est sur les nerfs chaque fois que quelque chose change. Si vous pouvez amener votre Premier ministre à vous raconter son histoire (peut-être en buvant la boisson de son choix), vous pouvez sympathiser avec lui et il peut devenir réceptif à l’“innovation”, c'est-à-dire à une bonne pratique de l'ingénierie logicielle. Pour parler des compromis en matière de confiance, de qualité, de ressources et de calendrier qui découlent des différentes approches de test, de l'examen du code par les pairs, des méthodes formelles (alias correction par construction).

Parlez dans sa langue : Utilisez une métaphore pour illustrer la taille du problème. Est-ce 40 000 lignes de code ? Dites-lui que c'est comme un meurtre mystérieux de 600 pages dans une langue étrangère. Si vous voulez changer quelque chose au milieu du chapitre 12, comment vous assurer que cela ne provoque pas une rupture de continuité avec le reste de l'histoire ?

Cherchez à obtenir l'adhésion des gens sur les moyens d'accroître la confiance envers une cible acceptable dans des limites économiques raisonnables. Vous n'arriverez pas à mettre en œuvre le niveau 5 du modèle de maturité des capacités du SEI du jour au lendemain. Mais vous pourrez peut-être passer de la question actuelle à “la suite de tests de régression automatisés est-elle satisfaisante ?” et “comment exprimer cette nouvelle exigence dans le système de tests de régression ?

Je répondrais de la manière la plus mathématique, en considérant qu'il demande une probabilité avec une confiance de 100%, et en ignorant complètement l'effet que les distributions statistiques auraient sur ce nombre : vous devriez lui donner 2 ou 3 nombres, avec la confiance associée : 1 semaine à 90%, 2 semaines à 95%, 6 mois à 100%. Le dernier chiffre était une exagération mais je suis sûr que vous avez compris.

Voir l'article de Wikipedia sur les intervalles de confiance pour plus de lecture.