Solutions des Exercices 1 à 5

Gestion Avancée de la Confiance dans l’IoT

Dr. K. SOUADIH
École Supérieure en Technologies de l’Information et du Numérique

Année Universitaire 2025/2026

Table des matières

1 Exercice 1 : Architecture IoT en Couches 2
1.1 Question a) Les 5 couches du modèle ISO/IEC 30141 . . . . . . . . . . . . . . . . 2
1.2 Question b) Composants et technologies . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Question c) Trois vulnérabilités par couche . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Question d) Contre-mesures de sécurité . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Exercice 2 : Comparaison des Protocoles IoT 4

2.1 Question a) Sélection des protocoles . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Question b) Justification détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Question c) Mécanismes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Question d) Limitations majeures . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Exercice 3 : Analyse de l’Attaque Mirai 5

3.1 Question a) Les 5 étapes de l’attaque Mirai . . . . . . . . . . . . . . . . . . . . . 5
3.2 Question b) Vulnérabilité des credentials par défaut . . . . . . . . . . . . . . . . . 5
3.3 Question c) 4 mesures préventives . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Question d) Signatures IDS/IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Question e) Calcul de bande passante . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Exercice 4 : Propriétés de la Confiance (Détaillé) 7

4.1 Question a) Non-transitivité de la confiance . . . . . . . . . . . . . . . . . . . . . 7
4.2 Question b) Propriété illustrée dans le Scénario 2 . . . . . . . . . . . . . . . . . . 7
4.3 Question c) Exemple d’asymétrie de la confiance . . . . . . . . . . . . . . . . . . 8
4.4 Question d) Dynamisme temporel de la confiance . . . . . . . . . . . . . . . . . . 8
4.5 Question e) Subjectivité de la confiance . . . . . . . . . . . . . . . . . . . . . . . 9

5 Exercice 5 : Modèle Beta Reputation (Détaillé) 11

5.1 Contexte et données initiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Question a) Calcul des paramètres α et β . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Question b) Calcul de l’espérance de confiance . . . . . . . . . . . . . . . . . . . . 11
5.4 Question c) Calcul de la variance . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5 Question d) Interprétation de la variance . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Question e) Mise à jour après 10 nouvelles transmissions . . . . . . . . . . . . . . 13
5.7 Question f) Comparaison et analyse de l’évolution . . . . . . . . . . . . . . . . . 13
5.8 Question g) Valeurs initiales pour un capteur neuf . . . . . . . . . . . . . . . . . 14

1
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

1 Exercice 1 : Architecture IoT en Couches

1.1 Question a) Les 5 couches du modèle ISO/IEC 30141
Pour un système de surveillance environnementale d’une ferme intelligente :
1. Couche Perception (Capteurs)
— Collecte des données environnementales
— Interaction directe avec l’environnement physique
2. Couche Réseau (Transport)
— Transmission des données collectées
— Connexion entre capteurs et passerelles
3. Couche Middleware (Traitement)
— Agrégation et prétraitement des données
— Gestion des protocoles hétérogènes
4. Couche Application
— Analyse des données
— Interfaces utilisateur et tableau de bord
5. Couche Business
— Prise de décision
— Génération de rapports et analytics

1.2 Question b) Composants et technologies

Couche Composants/Technologies
Perception 1. Capteurs DHT22 (température/humidité)
2. Capteurs NPK pour analyse du sol
Réseau 1. LoRaWAN (longue portée, faible consommation)
2. Zigbee (réseau maillé local)
Middleware 1. Node-RED (orchestration de flux)
2. Apache Kafka (streaming de données)
Application 1. Plateformes IoT (ThingsBoard, AWS IoT)
2. Applications web/mobile personnalisées
Business 1. Systèmes d’aide à la décision agricole
2. Outils de Business Intelligence (Power BI)

1.3 Question c) Trois vulnérabilités par couche

Analyse de criticité :
Les vulnérabilités les plus critiques pour une ferme intelligente sont :
1. Couche Réseau : Communications non chiffrées (impact sur toutes les données)
2. Couche Perception : Accès physique (sabotage agricole, vol de matériel coûteux)
3. Couche Middleware : APIs non sécurisées (pivot vers infrastructure complète)

2
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

Couche Vulnérabilités
Perception 1. Accès physique non sécurisé : Capteurs déployés en extérieur sans pro-
tection, permettant sabotage ou vol
2. Absence de chiffrement local : Données stockées en clair dans la mé-
moire du capteur
3. Firmware obsolète : Aucun mécanisme de mise à jour automatique,
vulnérabilités connues non patchées
Réseau 1. Communications en clair : Protocoles sans chiffrement (MQTT sans
TLS), vulnérabilité MITM
2. Absence d’authentification mutuelle : Gateway accepte n’importe quel
capteur sans vérification d’identité
3. Attaques de rejeu : Pas de nonce/timestamp, possibilité de rejouer des
messages capturés
Middleware 1. Injections dans les bases de données : Validation insuffisante des en-
trées, permettant SQL/NoSQL injection
2. APIs non sécurisées : Endpoints sans authentification ou avec tokens
statiques
3. Logs sensibles : Enregistrement de données personnelles/credentials
en clair dans les logs
Application 1. Vulnérabilités web classiques : XSS, CSRF sur les interfaces de gestion
2. Authentification faible : Mots de passe simples acceptés, pas de 2FA
3. Gestion de sessions : Tokens sans expiration, pas de révocation pos-
sible
Business 1. Fuites de données : Exports non chiffrés, partage via email non sécu-
risé
2. Absence d’audit trail : Pas de traçabilité des accès aux données sen-
sibles
3. Non-conformité RGPD : Absence de consentement explicite, pas de
mécanisme de suppression des données

1.4 Question d) Contre-mesures de sécurité

1. Couche Perception :
— Boîtiers anti-vandalisme et scellés inviolables
— Chiffrement AES-128 des données à la source
— Mise en place d’un système OTA (Over-The-Air) pour les mises à jour
2. Couche Réseau :
— Utilisation de DTLS pour chiffrer les communications
— Implémentation de certificats X.509 pour l’authentification
— Rate limiting et détection d’anomalies de trafic
3. Couche Middleware :
— Validation stricte des entrées (parameterized queries)
— Implémentation d’OAuth 2.0 avec JWT pour les APIs
— Anonymisation des logs sensibles
4. Couche Application :
— WAF (Web Application Firewall) avec règles OWASP
— Authentification multi-facteurs (2FA/MFA)
— Tokens de session avec expiration courte
5. Couche Business :
— Chiffrement des exports (PGP/GPG)
— SIEM pour la traçabilité et l’audit
— Analyse d’impact RGPD (DPIA) et pseudonymisation

3
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

2 Exercice 2 : Comparaison des Protocoles IoT

2.1 Question a) Sélection des protocoles

Application Protocole Justification

A : Monitoring urbain LoRaWAN Portée 5 km, faible débit acceptable, très
basse consommation
B : Wearables santé BLE 5.3 Portée 50m, faible latence (<100ms), op-
timisé pour wearables
C : Compteurs ruraux NB-IoT Portée 20 km, excellente pénétration, très
faible consommation

2.2 Question b) Justification détaillée

Application A - LoRaWAN :
— Portée : 2-15 km (idéal pour 5 km urbain)
— Débit : 0.3-50 kbps (suffisant pour données de stationnement)
— Énergie : Batterie jusqu’à 10 ans
— Sécurité : AES-128 (chiffrement de bout en bout)
Application B - BLE 5.3 :
— Portée : 40-240m (couvre les 50m requis)
— Débit : Jusqu’à 2 Mbps (amplement suffisant)
— Latence : <10ms possible (bien en dessous de 100ms)
— Sécurité : AES-128 CCM, ECDH pour échange de clés
Application C - NB-IoT :
— Portée : Jusqu’à 35 km en zone rurale
— Débit : 250 kbps downlink (adéquat pour compteurs)
— Énergie : PSM et eDRX permettent 10+ ans sur batterie
— Sécurité : Intégration réseau LTE (authentification SIM)

2.3 Question c) Mécanismes de sécurité

— LoRaWAN : AES-128 (AppKey, NwkKey), authentification OTAA/ABP, intégrité MIC
— BLE 5.3 : Pairing LE Secure Connections, ECDH P-256, AES-CCM, privacy features
— NB-IoT : Authentification SIM (AKA), chiffrement sur interface radio, IPsec optionnel

2.4 Question d) Limitations majeures

— LoRaWAN : Débit très limité, latence élevée (classe A), duty cycle restrictif (1%)
— BLE 5.3 : Portée limitée, nécessite proximité smartphone/gateway
— NB-IoT : Coût de connectivité (abonnement opérateur), latence variable

4
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

3 Exercice 3 : Analyse de l’Attaque Mirai

3.1 Question a) Les 5 étapes de l’attaque Mirai
1. Scan : Balayage massif d’adresses IP sur les ports Telnet (23, 2323)
2. Brute-force : Tentative de connexion avec 60+ combinaisons login/mot de passe par
défaut
3. Infection : Téléchargement et exécution du binaire Mirai sur le device compromis
4. Rapport : Le bot infecté communique avec le serveur C&C (Command & Control)
5. Attaque DDoS : Le botnet lance des attaques coordonnées (HTTP flood, UDP flood,
GRE flood)

3.2 Question b) Vulnérabilité des credentials par défaut

Les credentials par défaut constituent une vulnérabilité critique car :
— Prévisibilité : Combinaisons connues et publiques (admin/admin, root/12345)
— Échelle : Des millions de devices utilisent les mêmes credentials
— Persistance : Utilisateurs ne changent jamais ces mots de passe
— Accessibilité : Exposition directe sur Internet sans firewall

3.3 Question c) 4 mesures préventives

1. Mots de passe uniques : Génération aléatoire par device avec étiquette physique
2. Changement forcé : Obligation de modifier le mot de passe au premier démarrage
3. Désactivation Telnet : Utilisation de SSH uniquement avec authentification par clé
4. Firmware sécurisé : Mises à jour automatiques et signature cryptographique

3.4 Question d) Signatures IDS/IPS

# Detection des scans Telnet massifs

alert tcp any any -> $HOME_NET 23 ( msg : " Mirai ␣ Scan " ;
flags : S ; threshold : type threshold , track by_src ,
count 20 , seconds 60;)

# Detection brute - force credentials

alert tcp any any -> $HOME_NET 23 ( msg : " Mirai ␣ Brute - force " ;
content : " admin " ; nocase ; pcre : " / admin | root | user / i " ;
threshold : type threshold , count 10 , seconds 30;)

# Detection de communication C & C

alert tcp $HOME_NET any -> any any ( msg : " Mirai ␣ C & C " ;
content : " reports . txt " ; offset :0; depth :12;)

# Detection des patterns GRE flood

alert ip any any -> any any ( msg : " Mirai ␣ GRE ␣ Flood " ;
ip_proto :47; threshold : type both , track by_src ,
count 100 , seconds 1;)

5
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

3.5 Question e) Calcul de bande passante

Données :
— Nombre de devices : 500,000
— Trafic par device : 1.2 Mbps
Calcul :

Bande passante totale = 500,000 × 1.2 Mbps = 600,000 Mbps

Bande passante totale = 600 Gbps = 0.6 Tbps

Contexte : Cette capacité d’attaque a permis à Mirai de neutraliser des infrastructures
majeures comme Dyn DNS en octobre 2016, affectant Twitter, Netflix, GitHub, etc.

6
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

4 Exercice 4 : Propriétés de la Confiance (Détaillé)

4.1 Question a) Non-transitivité de la confiance
Analyse du Scénario 1 :
— Capteur A → Gateway B : Trust = 0.8
— Gateway B → Serveur Cloud C : Trust = 0.9
Réponse : Non, on ne peut PAS déduire automatiquement que A fait confiance
à C.
Explication détaillée :
La confiance n’est pas transitive dans les systèmes IoT pour plusieurs raisons fondamen-
tales :
1. Contextes différents :
— A évalue B sur sa capacité à relayer des données localement
— B évalue C sur sa capacité à stocker et traiter dans le cloud
— Ces deux évaluations portent sur des aspects complètement différents
2. Absence de connaissance directe :
— A n’a jamais interagi directement avec C
— A ne peut pas vérifier les claims de sécurité de C
— La réputation de C vue par B peut être différente de celle que A observerait
3. Chaîne de confiance affaiblie :
— Même si on multipliait naïvement : 0.8 × 0.9 = 0.72
— Cette approche ignore les risques cumulatifs et les points de défaillance
— Chaque intermédiaire introduit des vulnérabilités supplémentaires
Solution pratique :
— A doit établir sa propre évaluation de confiance envers C
— Utiliser la recommandation de B comme information initiale uniquement
— Implémenter une confiance déléguée explicite avec vérification cryptographique (chaînes
de certificats)

4.2 Question b) Propriété illustrée dans le Scénario 2

Scénario 2 :
— Device D → Device E : Trust = 0.7 (transmission de données)
— Device D → Device E : Trust = 0.3 (exécution de commandes critiques)
Propriété illustrée : Contextualité (Context-Dependency)
Définition complète :
La confiance est contextuelle, c’est-à-dire qu’elle dépend du domaine d’application ou du
type d’interaction. Un même agent peut être jugé digne de confiance dans un contexte mais pas
dans un autre.
Analyse approfondie :
1. Trust = 0.7 pour transmission de données :
— E est considéré relativement fiable pour relayer des mesures
— Les risques sont limités : perte de paquets, corruption mineure
— L’impact d’une défaillance est faible (redondance possible)
2. Trust = 0.3 pour commandes critiques :

7
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

— E n’est pas jugé suffisamment fiable pour des actions irréversibles

— Les risques sont élevés : arrêt de production, dommages physiques
— L’impact d’une malveillance ou erreur serait catastrophique
Formulation mathématique :
La confiance peut être modélisée comme une fonction multi-dimensionnelle :

T rustD (E) = {Tdata , Tcontrol , Tcomputation , . . .}

Où chaque composante représente un contexte spécifique.
Exemple concret dans l’IoT industriel :
Un capteur de température peut être :
— Très fiable (Trust = 0.9) pour la surveillance passive
— Peu fiable (Trust = 0.2) pour déclencher un arrêt d’urgence

4.3 Question c) Exemple d’asymétrie de la confiance

Propriété : Asymétrie
La confiance est asymétrique : si A fait confiance à B, cela n’implique pas que B fait
confiance à A.
Exemple concret IoT :
Système de maison intelligente avec assistant vocal
— Utilisateur → Assistant vocal (Alexa) : Trust = 0.85
— L’utilisateur fait confiance à Alexa pour contrôler les lumières
— Il lui confie des commandes vocales avec données personnelles
— Il s’attend à un service fiable et sécurisé
— Assistant vocal (Alexa) → Utilisateur : Trust = 0.3
— Le système doit authentifier l’utilisateur (reconnaissance vocale)
— Il ne peut pas "faire confiance" aveuglément aux commandes vocales
— Protection contre les attaques par replay ou usurpation
Autre exemple : Blockchain IoT
Dans une blockchain de supply chain :
— Un nœud validateur fait fortement confiance aux données d’un capteur certifié (Trust =
0.95)
— Le capteur ne "fait pas confiance" au nœud dans le sens où il n’attend rien de lui (relation
unidirectionnelle)

4.4 Question d) Dynamisme temporel de la confiance

Pourquoi la confiance doit être dynamique :
La confiance évolue dans le temps en fonction :
1. Des nouvelles interactions (succès/échecs)
2. Des changements de contexte environnemental
3. De l’obsolescence des évaluations passées
4. Des mises à jour de sécurité ou compromissions

8
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

Formule de mise à jour temporelle :

T rustt+1 = λ · T rustt + (1 − λ) · T rustobserved

Où λ ∈ [0, 1] est un facteur de décroissance.
Situation 1 : Dégradation progressive
Capteur de qualité de l’air urbain
— T = 0 mois : Trust = 0.95 (capteur neuf, calibré)
— T = 6 mois : Trust = 0.80 (dérive de calibration, poussière)
— T = 12 mois : Trust = 0.60 (nécessite maintenance)
— T = 18 mois : Trust = 0.30 (hors spécifications)
Mécanisme :
— Comparaison avec capteurs de référence
— Détection d’écarts statistiques croissants
— Décroissance exponentielle : T rust(t) = T rust0 · e−αt
Situation 2 : Récupération après incident
Gateway IoT victime d’une tentative d’intrusion
— Avant incident : Trust = 0.85 (opération normale)
— Détection intrusion : Trust = 0.20 (quarantaine immédiate)
— Après patch : Trust = 0.50 (remise en service surveillée)
— +30 jours sans incident : Trust = 0.75 (récupération progressive)
— +90 jours sans incident : Trust = 0.85 (confiance restaurée)
Mécanisme :
— Chute brutale lors de la détection (penalité)
— Récupération progressive avec observation comportementale
— Nécessite un historique positif prolongé
Formule avec fenêtre temporelle :
Pt −δ(t−i) · T rust
i=t−w e i
T rust(t) = Pt
e −δ(t−i)
i=t−w
Où w est la taille de la fenêtre et δ le taux de décroissance.

4.5 Question e) Subjectivité de la confiance

Définition de la subjectivité :
La confiance est subjective, c’est-à-dire que différents agents peuvent avoir des évaluations
de confiance différentes pour la même entité, basées sur leurs propres expériences, critères et
tolérances au risque.
Formulation :
Pour des agents A et B évaluant un agent C :

T rustA (C) ̸= T rustB (C)

Même avec les mêmes interactions observées.

Facteurs de subjectivité :
1. Historique d’interactions différent

9
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

— A a eu 100 interactions positives avec C

— B a eu 50 interactions dont 10 négatives
2. Seuils de tolérance variables
— A tolère 5% d’erreur (application non-critique)
— B ne tolère que 0.1% d’erreur (application médicale)
3. Pondérations différentes des critères
— A privilégie la latence (w_latence = 0.6)
— B privilégie la fiabilité (w_fiabilité = 0.7)
Impact sur les modèles distribués :
Dans un réseau SIoT (Social IoT), la subjectivité crée des défis :
1. Agrégation de recommandations :
— Comment combiner des évaluations subjectives hétérogènes ?
— Quelle pondération donner à chaque recommandation ?
Solution : Pondération basée sur la similarité des contextes
X
direct
T rustA (C) = wA · TA→C + sim(A, i) · Ti→C
i

2. Attaques par manipulation de réputation :

— Un attaquant peut exploiter la subjectivité
— Donner de bonnes recommandations à certains, mauvaises à d’autres
Solution : Détection de comportements incohérents
3. Consensus difficile :
— Pas de "vérité absolue" sur la confiance
— Nécessité de mécanismes de convergence
Solution : Algorithmes de consensus probabilistes (Bayésien)
Exemple concret :
Réseau de partage de données entre véhicules connectés
— Véhicule A (berline urbaine) : Trust(Véhicule_X) = 0.9
— Évalue X sur la précision des infos trafic en ville
— 95% des alertes de X étaient correctes pour les embouteillages
— Véhicule B (camion longue distance) : Trust(Véhicule_X) = 0.4
— Évalue X sur les alertes autoroute
— 60% des alertes de X sur autoroute étaient pertinentes pour un camion
— X ne signale pas les limitations de hauteur (non pertinent pour X)
Les deux évaluations sont correctes mais subjectives selon le contexte d’usage.

10
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

5 Exercice 5 : Modèle Beta Reputation (Détaillé)

5.1 Contexte et données initiales
Un capteur de température effectue 150 transmissions :
— Transmissions réussies : s = 127
— Transmissions échouées : f = 23
— Total : n = 150

5.2 Question a) Calcul des paramètres α et β

Dans le modèle Beta Reputation, les paramètres sont définis par :

α = s + 1 = 127 + 1 = 128

β = f + 1 = 23 + 1 = 24
Justification de l’ajout de 1 :
— Principe bayésien : On utilise un prior uniforme Beta(1,1)
— Évite division par zéro : Pour un capteur sans historique
— Prior neutre : Beta(1,1) = distribution uniforme sur [0,1]
Interprétation :
— α = 128 représente le nombre de succès observés + 1 observation virtuelle positive
— β = 24 représente le nombre d’échecs observés + 1 observation virtuelle négative

5.3 Question b) Calcul de l’espérance de confiance

L’espérance d’une distribution Beta(α, β) est :
α
E[Trust] =
α+β
Calcul :
128 128
E[Trust] = =
128 + 24 152

E[Trust] = 0.8421 ≈ 84.21%

Interprétation détaillée :
— Le capteur a une probabilité moyenne de succès de 84.21%
— C’est légèrement inférieur au taux brut : 127
150 = 0.8467
— La différence vient du prior bayésien qui "régularise" l’estimation
— Pour un grand nombre d’observations, E[Trust] ≈ s
s+f

11
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

5.4 Question c) Calcul de la variance

La variance d’une distribution Beta(α, β) est :

αβ
Var =
(α + β)2 (α + β + 1)
Calcul détaillé :
128 × 24
Var =
(128 + 24)2 × (128 + 24 + 1)
3072 3072
= 2
=
152 × 153 23104 × 153
3072
=
3534912

Var = 0.000869 ≈ 8.69 × 10−4

Écart-type :
√ √
σ= Var = 0.000869 ≈ 0.0295 ≈ 2.95%

5.5 Question d) Interprétation de la variance

Signification d’une variance élevée vs faible :
1. Variance faible (notre cas : 0.000869)
— Forte certitude : L’estimation de confiance est très fiable
— Historique riche : 150 observations suffisent pour une évaluation stable
— Convergence : Les futures observations changeront peu l’estimation
— Intervalle de confiance étroit :
IC95% ≈ [0.8421 − 1.96 × 0.0295, 0.8421 + 1.96 × 0.0295]
IC95% ≈ [0.784, 0.900]
2. Variance élevée (exemple : nouvel capteur)
— Incertitude importante : Peu de confiance dans l’estimation
— Historique limité : Peu d’observations disponibles
— Volatilité : Chaque nouvelle observation modifie significativement Trust
— Exemple numérique : Pour α = 3, β = 2 (4 observations)
3×2 6
Var = = = 0.04 (46× plus élevée)
52 × 6 150
Formule générale de la variance :
On observe que :
1 1
Var ∝ =
α+β n+2
La variance décroît avec le nombre d’observations, ce qui est intuitif :
Application pratique :
Dans un système IoT, on peut définir des seuils de confiance basés sur la variance :
— Si Var > 0.01 : Capteur "en observation" - ne pas utiliser pour décisions critiques
— Si 0.001 < Var < 0.01 : Capteur "fiable conditionnel" - usage modéré
— Si Var < 0.001 : Capteur "hautement fiable" - usage illimité

12
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

Observations (n) α+β Variance Écart-type

10 12 0.0067 8.2%
50 52 0.0016 4.0%
150 152 0.00087 2.9%
500 502 0.00026 1.6%

Table 1 – Évolution de la variance avec l’historique

5.6 Question e) Mise à jour après 10 nouvelles transmissions

Nouvelles données :
— 10 transmissions supplémentaires, toutes réussies
— Nouveaux totaux : s′ = 127 + 10 = 137, f ′ = 23, n′ = 160
Nouveaux paramètres :

α′ = 137 + 1 = 138

β ′ = 23 + 1 = 24 (inchangé)
Nouvelle espérance :
138 138
E[Trust]′ = =
138 + 24 162

E[Trust]′ = 0.8519 ≈ 85.19%

Nouvelle variance :
138 × 24
Var′ =
1622 × 163
3312 3312
= =
26244 × 163 4277772

Var′ = 0.000774 ≈ 7.74 × 10−4

√
σ′ = 0.000774 ≈ 0.0278 ≈ 2.78%

5.7 Question f ) Comparaison et analyse de l’évolution

Métrique Avant Après Variation

Observations (n) 150 160 +10
Paramètre α 128 138 +10
Paramètre β 24 24 0
E[Trust] 0.8421 0.8519 +0.0098 (+1.16%)
Variance 0.000869 0.000774 -0.000095 (-10.9%)
Écart-type 0.0295 0.0278 -0.0017 (-5.8%)

Table 2 – Évolution des métriques de confiance

Observations importantes :
1. Augmentation de la confiance :

13
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

— La confiance passe de 84.21% à 85.19% (+0.98 points)

— Amélioration modérée mais significative
— Tendance positive confirmée par 10 succès consécutifs
2. Réduction de l’incertitude :
— La variance diminue de 10.9%
— Plus d’observations = plus de certitude
— L’écart-type passe de 2.95% à 2.78%
3. Convergence progressive :
— L’impact de 10 observations sur 160 est plus faible que sur 10
— Phénomène attendu : ∆E ∝ n1
— Le capteur est de plus en plus "stable" dans son évaluation
4. Propriété de mémoire :
— Le modèle conserve tout l’historique
— Les 23 échecs passés "pèsent" toujours dans l’évaluation
— Impossible d’atteindre 100% de confiance sans oublier le passé
Taux de mise à jour :
On peut calculer l’impact relatif d’une nouvelle observation :

|E[Trust]′ − E[Trust]| 0.0098

Impact = = = 1.16%
E[Trust] 0.8421
Graphique d’évolution (conceptuel) :

Trust

n=150 : 0.8421 n=160 : 0.8519

0.85
0.84

Observations

5.8 Question g) Valeurs initiales pour un capteur neuf

Question : Si un capteur n’a aucun historique, quelles valeurs initiales donner à α et β ?
Réponse et justification :

α0 = 1, β0 = 1
Justifications théoriques et pratiques :
1. Prior uniforme bayésien :
— Beta(1,1) est une distribution uniforme sur [0,1]
— Représente une ignorance totale : toutes les valeurs de confiance sont équiprobables

14
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

— Principe de Laplace : en l’absence d’information, toutes les hypothèses sont équipro-

bables
2. Espérance neutre :
1
E[Trust]0 = = 0.5 = 50%
1+1
— Valeur neutre : ni optimiste, ni pessimiste
— Reflète l’incertitude maximale
3. Variance maximale :
1×1 1
Var0 = 2
= ≈ 0.0833
2 ×3 12
— Écart-type : σ0 = 0.289 ≈ 29%
— Très haute incertitude (96× plus que notre capteur établi)
— Signale clairement : "évaluation non fiable"
4. Apprentissage rapide initial :
— Les premières observations ont un impact maximal
— Après 1 succès : α = 2, β = 1 ⇒ E = 0.667 (+33%)
— Après 1 échec : α = 1, β = 2 ⇒ E = 0.333 (-33%)
— Le système s’adapte rapidement aux premières données
Alternatives possibles selon le contexte :

Stratégie α0 β0 Usage
Neutre 1 1 Standard, aucune présomption
Optimiste 5 1 Environnement de confiance, capteurs
certifiés
Pessimiste 1 5 Environnement hostile, sécurité cri-
tique
Conservatrice 10 10 Nécessite beaucoup d’observations
avant décision

Table 3 – Stratégies d’initialisation selon le contexte

Exemple avec prior optimiste :

Dans un réseau de capteurs certifiés industriellement :

α0 = 9, β0 = 1 ⇒ E[Trust]0 = 0.9 = 90%

— Présume que les capteurs certifiés sont fiables a priori
— Équivalent à "10 observations virtuelles dont 9 succès"
— Nécessite environ 10-20 échecs réels pour chuter significativement
— Approprié pour équipements garantis par le fabricant
Recommandation générale :
— Par défaut : α0 = 1, β0 = 1 (neutre)
— Si certification : α0 = 5 − 10, β0 = 1 (optimiste modéré)
— Si critique médical/militaire : α0 = 1, β0 = 3 (pessimiste)
— Phase de test : α0 = 2, β0 = 2 (légèrement conservateur)
Formule d’équivalence :
Un prior Beta(α0 , β0 ) équivaut à avoir observé :

nvirtual = α0 + β0 − 2 observations

15
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

Dont α0 − 1 succès et β0 − 1 échecs.

Synthèse Exercice 5 :
Le modèle Beta Reputation offre un cadre probabiliste rigoureux pour évaluer la
confiance :
— Espérance : Estimation ponctuelle de la confiance
— Variance : Mesure de l’incertitude/fiabilité de l’estimation
— Mise à jour : Intégration continue de nouvelles observations
— Prior bayésien : Gestion élégante de l’absence d’historique
Notre capteur avec 127/150 succès obtient Trust = 84.21% ± 2.95%, ce qui est excellent
pour un usage non-critique et acceptable pour un usage critique avec supervision.

16
ESTIN 2025/2026 Solutions TD - Gestion de Confiance IoT

Conclusion
Ces cinq premiers exercices couvrent les fondamentaux de la gestion de confiance dans l’IoT :
1. Architecture en couches : Vision systémique avec identification des vulnérabilités
2. Protocoles IoT : Choix adaptés aux contraintes de portée, énergie et sécurité
3. Attaque Mirai : Analyse d’un cas réel majeur et mesures préventives
4. Propriétés de confiance : Compréhension approfondie des caractéristiques théoriques
5. Modèle Beta : Application pratique de calculs probabilistes de confiance
Compétences développées :
— Analyse architecturale sécuritaire
— Sélection de protocoles adaptés
— Modélisation mathématique de la confiance
— Interprétation statistique (variance, convergence)
— Prise de décision basée sur des métriques quantitatives

"In God we trust, all others must bring data."

— W. Edwards Deming (adapté au contexte IoT)

17