Ce qui vous est demandé
Jour 1 · Concevoir et construire · 20 min
Deux jours pour assembler ce que vous avez construit depuis le 3 août en un système que vous défendrez devant un jury. Aucune notion nouvelle : tout ce dont vous avez besoin est derrière vous.
Le cadre commun
Quel que soit le sujet retenu, le système doit comporter les cinq couches du parcours :
| Couche | Ce qui est attendu | Vu en |
|---|---|---|
| Acquisition | Au moins deux capteurs simulés, dont un ESP32 sous Wokwi | M2 |
| Traitement local | Filtrage et décision d'émission dans l'objet | M2 |
| Transport | MQTT en TLS, certificats clients, ACL cloisonnantes | M1 |
| Stockage | InfluxDB avec rétention et au moins un agrégat | M3 |
| Restitution | Tableau de bord et au moins une alerte durable | M4 |
| Sécurité | Audit, parade au rejeu, mise à jour signée | M5 |
Trois sujets au choix
Prenez celui qui vous parle — c'est vous qui le défendrez pendant vingt minutes.
| Sujet | Ce qu'il ajoute |
|---|---|
| A · Supervision énergétique — consommation électrique d'un bâtiment, détection de dérive et de talon de nuit | Le calcul d'un indicateur dérivé : la consommation se déduit d'un compteur cumulatif |
| B · Surveillance de chaîne du froid — température de chambres froides, alerte sur franchissement et sur durée | La contrainte réglementaire : toute rupture doit être tracée et prouvable |
| C · Qualité d'air intérieur — CO₂, température, humidité, recommandation d'aération | La corrélation entre trois grandeurs et une recommandation d'action |
Vous pouvez proposer autre chose, à condition que les six couches y soient et que l'encadrant le valide au jalon 1. Un sujet qui vous intéresse produira une meilleure soutenance qu'un sujet imposé.
La grille d'évaluation
La voici en entier, dès maintenant. Vous devez savoir sur quoi vous êtes jugée.
| Critère | Ce qui est regardé | Poids |
|---|---|---|
| Le système fonctionne | La démo tourne en direct. Une capture d'écran ne remplace pas une démonstration | ●●● |
| Reproductibilité | docker compose up sur un poste neuf remonte l'ensemble | ●●● |
| Sécurité effective | TLS, ACL, parade au rejeu — et vous savez montrer qu'elles agissent | ●●● |
| Justification des choix | Pourquoi ce filtre, ce QoS, cette rétention. Un choix non justifié vaut un choix subi | ●●● |
| Comportement en panne | Ce qui se passe quand un capteur tombe, quand le broker tombe | ●● |
| Rapport technique | Architecture, flux, sécurité, performances, limites | ●● |
| Soutenance | Vingt minutes tenues, démo maîtrisée, réponses aux questions | ●● |
L'élégance du code Python. La beauté du tableau de bord au-delà de sa lisibilité. Le nombre de fonctionnalités.
Un système simple, qui tourne, dont chaque choix est justifié, vaut mieux qu'un système ambitieux à moitié fini. C'est le conseil le plus utile de cette page.
Concevoir avant de coder
Jour 1 · Concevoir et construire · 20 min
La tentation est d'ouvrir un terminal immédiatement. Deux heures de conception vous en feront gagner six.
Ce que le jalon 1 exige
À 11 h ce matin, vous présentez à votre encadrant quatre choses. Pas de code, pas de maquette : des décisions.
- Un schéma d'architecture. Les composants, ce qui circule entre eux, où sont les frontières de confiance.
- Le modèle de données. Vos topics MQTT, vos tags et fields InfluxDB. Les tags conditionnent tout le reste — c'est le choix le plus difficile à corriger après coup.
- Les paramètres, avec leur justification. Cadence de mesure, filtre et son réglage, seuil d'émission, QoS, rétention. Chaque valeur doit avoir une raison.
- Ce que vous ne ferez pas. En deux jours, vous devrez renoncer à des choses. Les nommer d'emblée est un signe de maîtrise, pas d'échec.
Faites-en un tableau à trois colonnes : paramètre, valeur retenue, raison. C'est l'artefact le plus utile de votre rapport, et le jury s'en servira pour ses questions.
Le piège des deux jours
| Erreur | Conséquence | Parade |
|---|---|---|
| Vouloir tout refaire proprement | Rien ne tourne le jeudi soir | Repartez de vos maquettes existantes |
| Ajouter une technologie non vue | Blocage sur un problème hors sujet | Restez dans ce que vous maîtrisez |
| Coder d'abord, concevoir ensuite | Modèle de données à refaire à mi-parcours | Le jalon 1 existe pour ça |
| Soigner le tableau de bord avant que la chaîne tourne | Belle façade, système creux | L'ordre des jalons est délibéré |
Jeudi 17 h, la chaîne complète doit tourner. Si à 15 h elle ne tourne pas, réduisez le périmètre plutôt que de continuer : un système à deux capteurs qui fonctionne se défend, un système à cinq capteurs en panne ne se défend pas.
Jalon 1 — La conception
Jour 1 · Concevoir et construire · 2 h
Produire et faire valider les décisions structurantes avant d'écrire une ligne.
Présentation à votre encadrant à 11 h. Il valide ou demande des corrections — vous ne passez pas au jalon 2 sans cette validation.
- Choisissez votre sujet parmi les trois proposés, ou formulez le vôtre en trois lignes.
- Dessinez le schéma d'architecture. À la main sur papier convient parfaitement — ce qui compte est que les frontières de confiance y apparaissent : qu'est-ce qui est dans votre périmètre de confiance, qu'est-ce qui n'y est pas.
- Écrivez votre convention de topics, en reprenant la logique de M1 :
# exemple pour le sujet A <parc>/<site>/<zone>/<compteur>/<grandeur> # et le topic de statut, et celui de consigne - Écrivez votre schéma InfluxDB. Pour chaque champ, dites si c'est un tag ou un field, et pourquoi :
measurement : ... tags : ... # ce sur quoi je filtrerai fields : ... # ce que je calculerai cardinalite estimee : ... series - Remplissez le tableau des paramètres : cadence, filtre et réglage, seuil d'émission, battement de cœur, plafond, QoS, rétention, seuils d'alerte. Une raison par ligne.
- Écrivez la liste de ce que vous ne ferez pas, avec pour chaque renoncement ce qu'il faudrait pour le faire.
- Présentez le tout à votre encadrant. Attendez-vous à des questions sur les tags : c'est le choix le plus coûteux à corriger.
- Quel est le point de votre architecture dont vous êtes le moins sûre ?
- Si vous deviez livrer en une journée au lieu de deux, que retireriez-vous en premier ?
Jalon 2 — La chaîne complète
Jour 1 · Concevoir et construire · 4 h 30
Faire circuler une donnée du capteur simulé jusqu'au tableau de bord.
Montez la chaîne maillon par maillon, en vérifiant chacun avant d'ajouter le suivant. Assembler tout puis chercher pourquoi rien ne marche est la façon la plus sûre de perdre l'après-midi.
- Repartez de vos travaux existants : le broker sécurisé de M1, le nœud de M2, la pile de M3, le tableau de bord de M4. Ne refaites rien de zéro.
- Maillon 1 — le broker en TLS avec vos nouveaux certificats et vos ACL. Vérifiez qu'une publication hors périmètre est refusée avant de continuer.
- Maillon 2 — vos capteurs, dont un ESP32 sous Wokwi. Vérifiez que les valeurs arrivent sur les bons topics.
- Maillon 3 — Telegraf vers InfluxDB. Vérifiez que les tags sont corrects : c'est ici que les erreurs de conception se révèlent.
- Maillon 4 — le tableau de bord, avec vos quatre chiffres d'état et au moins un graphique d'évolution.
- Maillon 5 — une alerte durable, avec son délai de confirmation.
- Rassemblez tout dans un
docker-compose.ymlunique et testez la reproductibilité — c'est un critère à trois points :docker compose down -v docker compose up -d # tout doit remonter : buckets, taches, tableau de bord, alertes - Ce qui ne remonte pas automatiquement doit être scripté ou documenté. Un tableau de bord Grafana s'exporte et se provisionne ; une tâche InfluxDB se crée par script.
- À 17 h, votre chaîne doit tourner. Si ce n'est pas le cas à 15 h, réduisez le périmètre et prévenez votre encadrant.
- Quel maillon vous a pris le plus de temps, et pourquoi ?
- Qu'est-ce qui ne remonte pas après un
down -v, et comment le corriger ?
Point de contrôle — jeudi 17 h
Jour 1 · Concevoir et construire · 15 min
docker compose up remonte l'ensemble, ou j'ai documenté les écartsFaites un dernier docker compose down -v && docker compose up -d et vérifiez que tout remonte. Découvrir demain matin que la pile ne redémarre pas coûterait la moitié de la journée qui vous reste.
Jalon 3 — Éprouver le système
Jour 2 · Éprouver et présenter · 3 h
Casser votre propre système pour savoir ce qu'il fait quand ça se passe mal.
Le jury vous demandera « et si le broker tombe ? ». La bonne réponse n'est pas une hypothèse : c'est « je l'ai fait, voici ce qui s'est passé ».
- Provoquez chaque panne, observez, mesurez, consignez. Une ligne par scénario :
| Panne provoquee | Ce qui se passe | Detecte en | Recuperation | |------------------------|-----------------|------------|--------------| | capteur coupe | | | | | broker arrete | | | | | InfluxDB arrete | | | | | Telegraf arrete | | | | | valeur aberrante | | | | | message rejoue | | | | | certificat expire | | | | - Pour le capteur coupé : chronométrez le délai de détection par chacun de vos mécanismes. Vous en avez potentiellement trois depuis M1, M3 et M4.
- Pour le broker arrêté : que font vos capteurs ? Se reconnectent-ils ? Les mesures émises pendant la coupure sont-elles perdues ? Mesurez, ne supposez pas.
- Pour InfluxDB arrêté : Telegraf met-il en mémoire tampon ? Combien de temps ? Que montre le tableau de bord pendant ce temps ?
- Rejouez un message capturé, comme en M5, et vérifiez que votre parade agit.
- Mesurez enfin les performances de bout en bout :
# latence : instant de mesure -> apparition sur le tableau de bord # debit : messages par minute supportes sans perte # volume : points en base apres 2 h, extrapolation a 1 an - Complétez le tableau. Une case « non testé » est acceptable ; une case inventée ne l'est pas — le jury le verra.
- Quelle panne a le pire comportement, et qu'est-ce qui l'améliorerait ?
- Votre système perd-il des données quelque part ? Où, et est-ce acceptable ?
Le rapport technique
Jour 2 · Éprouver et présenter · 15 min
Le rapport n'est pas un compte rendu de ce que vous avez fait. C'est un document qui permet à quelqu'un d'autre de comprendre, reprendre et exploiter votre système.
Le plan attendu
| Partie | Contenu | Longueur |
|---|---|---|
| 1. Le besoin | Le problème traité, en une demi-page, sans jargon | ½ page |
| 2. L'architecture | Schéma, composants, ce qui circule, frontières de confiance | 1 page |
| 3. Les choix | Votre tableau des paramètres, avec les raisons | 1 page |
| 4. La sécurité | Ce qui est en place, ce qui a été audité, ce qui reste ouvert | 1 page |
| 5. Le comportement en panne | Votre tableau du jalon 3 | 1 page |
| 6. Les limites | Ce que vous n'avez pas fait et ce qu'il faudrait | ½ page |
| 7. Reprendre le système | Comment le remonter de zéro | ½ page |
La partie 6. Un rapport qui nomme précisément ses limites inspire plus confiance qu'un rapport qui n'en a aucune. Le jury sait qu'en deux jours on ne fait pas tout — ce qu'il veut savoir, c'est si vous en avez conscience.
Une affirmation non vérifiée. « Le système supporte 100 capteurs » alors que vous en avez testé deux. Écrivez plutôt : « testé avec 2 capteurs ; l'extrapolation à 100 supposerait de vérifier tel point ».
Jalon 4 — Rapport et répétition
Jour 2 · Éprouver et présenter · 2 h
Écrire le rapport et répéter la démonstration jusqu'à ce qu'elle soit sûre.
- Rédigez le rapport selon le plan de la leçon. Cinq à six pages suffisent — la densité compte plus que la longueur.
- Relisez-le en vous demandant, pour chaque affirmation : puis-je le prouver ? Si non, reformulez en indiquant ce qui a réellement été testé.
- Préparez votre démonstration. Écrivez-en le déroulé minute par minute — improviser devant un jury est le meilleur moyen de perdre cinq minutes sur un terminal récalcitrant.
- Voici un déroulé qui fonctionne, à adapter :
0-2 min le besoin et le sujet retenu 2-5 min l'architecture au tableau 5-12 min DEMONSTRATION . le systeme tourne, les donnees arrivent . je coupe un capteur -> l'alerte part . je rejoue un message -> il est refuse 12-16 min trois choix expliques et justifies 16-18 min limites et suites 18-20 min questions - Répétez la démonstration en entier, au moins deux fois, en conditions réelles : depuis un
docker compose up, chronomètre en main. - Préparez un plan de repli : si la démo tombe en panne devant le jury, ayez une capture vidéo ou des captures d'écran de chaque étape. Le dire au jury est professionnel, rester bloqué ne l'est pas.
- Anticipez les questions. Les plus probables sont listées dans la leçon suivante — préparez une réponse pour chacune.
- Votre démonstration tient-elle en sept minutes, montre en main ?
- Que faites-vous si le Wi-Fi de Wokwi ne répond pas au moment de la démo ?
Tenir vingt minutes devant un jury
Jour 2 · Éprouver et présenter · 15 min
La soutenance dure vingt minutes. Elle évalue autant votre système que votre capacité à l'expliquer — c'est précisément ce qu'on attendra de vous en poste.
Trois règles
- Montrez, ne racontez pas. Sept minutes de démonstration en direct valent mieux que quinze de diapositives.
- Assumez les manques. « Je ne l'ai pas testé » est une réponse acceptable. Inventer ne l'est pas, et un jury technique le repère immédiatement.
- Justifiez, ne décrivez pas. « J'ai mis un filtre exponentiel avec alpha à 0,2 » n'apprend rien. « J'ai retenu 0,2 après avoir mesuré le compromis bruit / temps de réponse, voici les trois valeurs testées » montre un ingénieur.
Les questions à préparer
| Question probable | Ce qu'elle vérifie |
|---|---|
| Pourquoi ce niveau de QoS ? | Que vous n'avez pas pris le plus élevé par précaution |
| Que se passe-t-il si le broker tombe ? | Que vous l'avez testé — jalon 3 |
| Pourquoi ce champ est-il un tag et pas un field ? | Que vous comprenez la cardinalité |
| Combien de capteurs votre système supporte-t-il ? | Que vous distinguez ce qui est mesuré de ce qui est supposé |
| Un capteur est volé. Que faites-vous ? | Que la révocation est pensée |
| Pourquoi ne pas avoir utilisé une plateforme managée ? | Que le choix est argumenté, pas subi |
| Qu'est-ce que vous feriez différemment ? | Votre recul — c'est souvent la meilleure question |
« Qu'est-ce que vous feriez différemment ? » revient presque toujours. Préparez-la sérieusement : une réponse honnête et précise sur ce que vous avez appris en vous trompant vaut mieux que n'importe quelle démonstration réussie.
Le parcours S6 s'achève. Ce que vous avez construit — la maquette, le dossier de sécurité, le rapport — reste votre matière : c'est ce que vous reprendrez lors de votre prise de poste, et ce sur quoi vous vous appuierez pour former d'autres.
Prêt pour la soutenance
Jour 2 · Éprouver et présenter · 10 min
docker compose upArrivez vingt minutes avant. Lancez votre pile, vérifiez que les données arrivent, gardez vos terminaux ouverts et prêts.
Et rappelez-vous ce qui est évalué en premier : le système fonctionne, et vous savez pourquoi vous l'avez fait ainsi. Le reste vient après.