Reconnaissez des événements indépendants
Une serre automatisée mesure sa température avec un capteur qui fonctionne correctement 95 % du temps. Pour être plus sûr, l’ingénieur en installe trois. Mais trois capteurs, est-ce trois fois plus fiable ? Tout dépend de la façon dont on les combine, et surtout d’une hypothèse cachée : leurs pannes sont-elles indépendantes ?
L’indépendance est l’hypothèse la plus utilisée (et la plus mal utilisée) en probabilités. Dans ce chapitre, vous allez la définir proprement, apprendre à la reconnaître, et l’appliquer au calcul de fiabilité de notre serre.
Deux événements indépendants
Section intitulée « Deux événements indépendants »Intuitivement, et sont indépendants si savoir que s’est produit ne change rien à la probabilité de : . En remplaçant par sa définition, on obtient la forme qu’on retient, qui a l’avantage d’être symétrique et de fonctionner même si :
Pour vérifier une indépendance, on calcule les trois probabilités et on compare. Pour l’utiliser, on multiplie.
Si et sont indépendants, alors et le sont aussi, de même que et . C’est logique : si n’apporte aucune information sur , son contraire non plus. Ce résultat servira sans cesse, car on raisonne souvent sur « la panne » plutôt que sur « le bon fonctionnement ».
Indépendance d’une famille d’événements
Section intitulée « Indépendance d’une famille d’événements »Avec trois événements ou plus, la définition demande plus que l’indépendance de chaque paire. Les événements sont mutuellement indépendants si, pour tout sous-ensemble d’indices (de taille au moins 2) :
Le symbole désigne l’intersection de tous les événements d’indice dans , et le produit de leurs probabilités. Pour trois événements, cela fait quatre égalités : les trois paires, et le triplet.
Pourquoi tant d’exigence ? Parce que l’indépendance deux à deux ne suffit pas à garantir celle de l’ensemble.
En pratique, l’indépendance mutuelle se justifie rarement par le calcul. Elle se postule à partir de la situation physique : des lancers de dés distincts, des tirages avec remise, des composants fabriqués séparément et qui n’interagissent pas. C’est une hypothèse de modélisation, qu’il faut énoncer clairement.
Répéter une expérience : la règle du « au moins un »
Section intitulée « Répéter une expérience : la règle du « au moins un » »Quand on répète fois une expérience de façon indépendante, et que l’événement a la probabilité à chaque fois, la probabilité que ne se produise jamais vaut (produit de probabilités identiques). D’où la règle, déjà rencontrée avec les paris de dés du chapitre 1 :
Cette formule a des conséquences surprenantes. Un événement rare, de probabilité 1 % par jour, se produit au moins une fois en 100 jours avec une probabilité , et en 300 jours avec une probabilité de 0,95 environ. C’est pour cela qu’un défaut « rare » finit toujours par apparaître sur un système qui tourne longtemps, ou sur un grand parc de machines.
Le fil rouge : la fiabilité des capteurs de la serre
Section intitulée « Le fil rouge : la fiabilité des capteurs de la serre »Revenons à la serre. Chaque capteur fonctionne avec une probabilité (sa fiabilité), et l’on suppose d’abord que les trois capteurs tombent en panne indépendamment les uns des autres. Trois architectures sont possibles.
En série : le système ne marche que si tous les capteurs marchent (par exemple, trois capteurs qui mesurent trois zones différentes, toutes indispensables). Par indépendance :
Ajouter des composants en série dégrade la fiabilité.
En parallèle (redondance) : le système marche si au moins un capteur marche. On passe par le contraire, « tous en panne » :
Vote majoritaire (2 sur 3) : on garde la valeur donnée par au moins deux capteurs concordants, ce qui protège contre un capteur qui renvoie une valeur fausse. Le système marche si exactement deux capteurs marchent (3 façons de choisir le capteur en panne) ou si les trois marchent :
| Architecture | Formule | Fiabilité avec |
|---|---|---|
| Un seul capteur | 0,95 | |
| 3 en série | 0,857 | |
| 3 en parallèle | 0,999 875 | |
| Vote 2 sur 3 | 0,993 |
Quand l’indépendance tombe : la cause commune
Section intitulée « Quand l’indépendance tombe : la cause commune »Tout repose sur l’hypothèse d’indépendance. Supposons maintenant que deux capteurs en parallèle partagent la même alimentation, qui tombe en panne avec une probabilité de 1 %. Chaque capteur fonctionne si l’alimentation marche et s’il est lui-même en bon état : .
- Si l’on croyait les deux capteurs indépendants, on calculerait .
- En réalité, le système marche si l’alimentation marche et qu’au moins un capteur marche : .
La probabilité de panne réelle (1,25 %) est plus de trois fois celle du calcul naïf (0,35 %). Les pannes des deux capteurs sont dépendantes, car elles ont une cause commune. En sûreté de fonctionnement, on parle de mode commun ; c’est l’une des premières questions à poser devant un calcul de redondance.
Une simulation confirme ces chiffres et permet de tester des architectures plus compliquées sans refaire les calculs :
set.seed(10)n <- 1e6alim <- runif(n) > 0.01 # l'alimentation fonctionne (99 %)c1 <- runif(n) > 0.05 # le capteur 1 est en bon état (95 %)c2 <- runif(n) > 0.05 # le capteur 2 est en bon état (95 %)
systeme <- alim & (c1 | c2) # parallèle, mais alimentation communemean(systeme) # proche de 0.9875
# Les pannes des deux capteurs sont-elles indépendantes ?ok1 <- alim & c1; ok2 <- alim & c2mean(ok1 & ok2) - mean(ok1) * mean(ok2) # nettement positif : dépendanceLa dernière ligne compare à sur les données simulées : l’écart est positif, signe que les deux capteurs ont tendance à fonctionner (ou à tomber en panne) ensemble.
En résumé
Section intitulée « En résumé »- et sont indépendants si , ce qui équivaut à quand .
- L’indépendance passe aux contraires ; elle n’a rien à voir avec l’incompatibilité (deux événements incompatibles de probabilités non nulles sont dépendants).
- L’indépendance mutuelle d’une famille exige la factorisation pour tous les sous-ensembles ; l’indépendance deux à deux ne suffit pas.
- Pour répétitions indépendantes, .
- Fiabilité : en série , en parallèle , en vote 2 sur 3 .
- Une cause commune rend les pannes dépendantes et ruine les calculs de redondance faits sous hypothèse d’indépendance.
Exercices
Section intitulée « Exercices »Exercice · Indépendants ou non ?
facileOn tire une carte dans un jeu de 32 cartes (8 valeurs, du 7 à l’as, dans 4 couleurs). Les événements = « la carte est un as » et = « la carte est un cœur » sont-ils indépendants ? Et et = « la carte est un roi » ?
Voir la solution
, , et est l’as de cœur : . Donc et sont indépendants : savoir que la carte est un cœur ne change pas la chance d’avoir un as.
et sont incompatibles (une carte ne peut pas être à la fois un as et un roi), donc . Ils sont dépendants.
En code
import pandas as pd
# Les 32 cartes : 8 valeurs dans 4 couleurs, toutes équiprobablesvaleurs = ["7", "8", "9", "10", "valet", "dame", "roi", "as"]couleurs = ["coeur", "carreau", "trefle", "pique"]jeu = pd.DataFrame([(v, c) for v in valeurs for c in couleurs], columns=["valeur", "couleur"])
A = jeu.valeur == "as"B = jeu.couleur == "coeur"C = jeu.valeur == "roi"
# On compare P(A et B) au produit P(A) P(B)print((A & B).mean(), A.mean() * B.mean()) # 0.03125 0.03125 -> indépendantsprint((A & C).mean(), A.mean() * C.mean()) # 0.0 0.015625 -> dépendants# Les 32 cartes : 8 valeurs dans 4 couleurs, toutes équiprobablesjeu <- expand.grid(valeur = c(7:10, "valet", "dame", "roi", "as"), couleur = c("coeur", "carreau", "trefle", "pique"))
A <- jeu$valeur == "as"B <- jeu$couleur == "coeur"C <- jeu$valeur == "roi"
# On compare P(A et B) au produit P(A) P(B)c(mean(A & B), mean(A) * mean(B)) # 0.03125 0.03125 -> indépendantsc(mean(A & C), mean(A) * mean(C)) # 0 0.015625 -> dépendantsExercice · Combien de capteurs ?
moyenDes capteurs bon marché ont une fiabilité de 0,9 chacun et tombent en panne indépendamment. Combien faut-il en installer en parallèle pour que le système fonctionne avec une probabilité d’au moins 0,9999 ?
Voir la solution
Avec capteurs en parallèle, . On veut , soit , donc .
Il faut 4 capteurs. Avec 3, on n’atteint que . En R : 1 - 0.1^(1:5) affiche les fiabilités pour 1 à 5 capteurs.
En code
import numpy as np
n = np.arange(1, 6)fiabilite = 1 - 0.1 ** n # n capteurs en parallèlefor k, r in zip(n, fiabilite): print(k, round(r, 5)) # 1 0.9 / 2 0.99 / 3 0.999 / 4 0.9999 / 5 0.99999
# Plus petit n tel que R >= 0.9999 (petite marge pour les arrondis machine)print(n[fiabilite >= 0.9999 - 1e-12][0]) # 4n <- 1:5fiabilite <- 1 - 0.1^n # n capteurs en parallèlefiabilite # 0.9 0.99 0.999 0.9999 0.99999
# Plus petit n tel que R >= 0.9999 (petite marge pour les arrondis machine)min(n[fiabilite >= 0.9999 - 1e-12]) # 4Exercice · Un montage mixte
difficileLa serre utilise maintenant trois capteurs indépendants de fiabilité 0,9 : les capteurs A et B sont montés en série (il faut les deux), et ce bloc est monté en parallèle avec le capteur C.
- Calculez la fiabilité du système.
- Sachant que le système fonctionne, quelle est la probabilité que le capteur C soit en panne ?
Voir la solution
-
Le bloc série fonctionne avec probabilité . Le système tombe en panne seulement si le bloc et C sont en panne, ce qui arrive avec probabilité par indépendance. Donc .
-
On cherche . Si C est en panne, le système marche seulement grâce au bloc A-B : . Donc :
C’est un peu moins que la probabilité de panne a priori de C (0,1) : savoir que le système marche rend légèrement plus probable que C marche aussi.
En code
import numpy as np
p = 0.9bloc_ab = p * p # A et B en sérieR = 1 - (1 - bloc_ab) * (1 - p) # bloc en parallèle avec Cprint(R) # 0.981print((1 - p) * bloc_ab / R) # 0.0826 P(C en panne | système OK)
# Vérification par simulationrng = np.random.default_rng(0)a, b, c = rng.random((3, 1_000_000)) < p # chaque capteur marche avec proba 0.9ok = (a & b) | cprint(ok.mean(), (~c[ok]).mean()) # 0.9808 0.0821p <- 0.9bloc_ab <- p * p # A et B en sérieR <- 1 - (1 - bloc_ab) * (1 - p) # bloc en parallèle avec CR # 0.981(1 - p) * bloc_ab / R # 0.0826 P(C en panne | système OK)
# Vérification par simulationset.seed(0)n <- 1e6a <- runif(n) < p; b <- runif(n) < p; c_ok <- runif(n) < pok <- (a & b) | c_okmean(ok); mean(!c_ok[ok]) # 0.9809 0.0830