DevFest Perros-Guirec 2024

Dev, cloud & sécu4 octobre 2024Perros-Guirec, Palais des Congrès4e édition

Thème : L'IoT et les systèmes embarqués pour les devs

Une journée mono-track sur l'IoT vu du terrain : réseaux (cellulaire, LoRa, NATS), bornes de charge, déchets, domotique et dashboards, avec en fil rouge la durée de vie longue des objets, la sécurité imposée par le Cyber Resilience Act et des utilisateurs finaux rarement techniciens.

7 sessions résumées · 7 vidéos · mise à jour le vendredi 9 octobre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme officiel (archives du site Code d'Armor, page GDG Community), transcripts automatiques des 7 vidéos de la playlist officielle « DevFest Perros-Guirec 2024 » publiées le 18 octobre 2024. Six recherches web menées en octobre 2026, deux ans après l'événement, sans retour participant trouvé.

Limites : Aucun retour de participant n'a été trouvé : les résumés disent ce qui a été dit sur scène, pas ce que la salle en a retenu. Les transcripts sont des sous-titres automatiques (noms propres et chiffres parfois déformés, les plus douteux ont été écartés). Le talk de Thales « Où est Charlie ? », le mot d'introduction et le mot de la fin n'ont pas de vidéo.

Synthèse globale

1. L'IoT n'est plus une hype, c'est de l'exploitation au long cours

Le thème annonçait un IoT devenu « commodité », et les talks l'ont confirmé : on n'y parlait pas de prototypes mais de parcs installés depuis des années. Pascal Fifre (Eco-Compteur) raisonne en durée de vie de 10 ans et en extinction des réseaux 2G et 3G ; Pierre Renault (Rennes Métropole) en huit ans de réseau LoRa et en passage de 5 000 à 60 000 capteurs ; Fulup Ar Foll (IoT.bzh) en bornes qui tournent 10 à 15 ans et dont il faut régénérer les rapports d'audit à chaque modification. La question centrale devient la pérennité : d'une techno radio, d'un fournisseur, d'une chaîne de dépendances.

2. Le terrain contredit toujours la théorie

Plusieurs speakers ont insisté sur l'écart entre le plan et le terrain. Rennes Métropole a appris que les cartes de couverture « ça suffit jamais » ; Eco-Compteur fait voyager ses compteurs autour du monde et a subi quatre ans de retard des opérateurs sur LTE-M ; Heyliot et Eco-Compteur fournissent une appli qui confirme la transmission avant que l'installateur ne reparte. Les produits finissent sous l'eau, sous la neige ou dans une boîte métallique posée par un client.

3. Des utilisateurs finaux qui ne sont pas des développeurs

Agents de collecte gantés qui travaillent la nuit (Tony Chouteau, Mobil-inn), agents techniques communaux peu à l'aise avec le numérique (Pierre Renault), installateurs de distributeurs étrangers (Pascal Fifre) : la valeur de l'IoT passe par des interfaces très simples, des alertes par mail ou SMS et des données filtrées. Pierre Papin (SenX) pousse la même logique côté supervision : un carré vert quand tout va bien, plutôt que 500 courbes à parcourir.

4. La sécurité et la réglementation arrivent

Le Cyber Resilience Act est cité par Eco-Compteur et Rennes Métropole, avec NIS 2, comme une contrainte qui tombe « pour le meilleur et pour le pire » sans qu'on sache encore exactement quoi faire. Fulup Ar Foll et Thomas Leseney (Netvolt) se rejoignent sur le rejet du modèle du « château fort » au profit d'une sécurité distribuée ou zero trust, chaque objet étant une porte d'entrée potentielle. Rennes Métropole en tire une règle simple : refuser sur son réseau les usages liés à la sécurité des personnes et des biens.

5. Simplifier la pile logicielle

Plusieurs talks plaident pour moins de briques. Thomas Leseney remplace quatre à six technologies (MQTT, Kafka, Redis, service mesh) par NATS seul ; Pierre Papin oppose à Grafana un dashboard écrit en code, avec une seule requête pour toutes les tuiles ; Pierre Andrieux (Capgemini) recommande l'installation la plus intégrée de Home Assistant. Rennes Métropole fait le même pari à l'échelle d'un territoire : un réseau mutualisé plutôt qu'une offre verticale par service urbain.

6. Tensions et biais du corpus

Le débat le plus net porte sur Rust : Fulup Ar Foll salue l'analyse statique de la mémoire mais juge le packaging, l'absence de compatibilité binaire et l'inflation de dépendances indéfendables, pour un verdict « bon mais pas exceptionnel » qu'il présente lui-même comme une opinion personnelle. Pierre Renault pointe un cadre juridique inadapté qui a maintenu le réseau rennais en « expérimentation » pendant des années. Cette synthèse repose uniquement sur les transcripts automatiques de sept vidéos et sur le programme : aucun retour de participant n'a été trouvé en ligne, et le talk de Thales sur OpenSearch, non filmé, n'est connu que par son descriptif.

Actions concrètes citées

  1. Choisir une techno radio d'abord pour sa couverture et sa pérennité (10 ans de durée de vie visée) et anticiper l'extinction 2G/3G, quitte à remplacer des parcs par vagues (Pascal Fifre, Eco-Compteur).
  2. Ne pas croire les études de couverture théoriques : toujours vérifier sur le terrain, et fournir aux installateurs une appli qui confirme la transmission avant de partir (Pierre Renault, Rennes Métropole ; Pascal Fifre ; Aurélien Conte, Heyliot).
  3. Sécuriser un objet connecté par démarrage signé, vérification de chaque mise à jour et isolation des blocs (MAC, namespaces, microservices), et tout mettre sous Git pour pouvoir reconstruire le système (Fulup Ar Foll, IoT.bzh).
  4. Placer dans un cœur temps réel (Zephyr sur Cortex-M) ce qui touche à la sûreté, car 15 000 lignes se certifient bien plus facilement que les millions de lignes de Linux (Fulup Ar Foll).
  5. Surveiller la chaîne de dépendances (SBOM) : en Rust comme en Python ou JavaScript, une petite fonction peut tirer des dizaines de paquets peu maintenus (Fulup Ar Foll).
  6. Découpler producteurs et consommateurs de données dans l'espace (pub/sub) puis dans le temps (flux persistés), et prévoir des sites qui fonctionnent sans réseau puis se resynchronisent (Thomas Leseney, Netvolt).
  7. Refuser de porter sur un réseau mutualisé les usages liés à la sécurité des personnes et des biens (Pierre Renault, Rennes Métropole).
  8. Pour la domotique, commencer petit avec du matériel de récupération et viser l'OS Home Assistant plutôt que la version conteneur, plus pénible à mettre à jour (Pierre Andrieux, Capgemini).
  9. Dans un tableau de bord IoT, n'afficher que ce qui pose problème et mutualiser les requêtes entre tuiles plutôt qu'une requête par tuile (Pierre Papin, SenX).

Session par session

Vendredi 4 octobre

Conférence▶ vidéo + transcript

Mise en œuvre de l'IoT chez EcoCompteur

Pascal Fifre — Eco-Compteur

  • Retour d'expérience du responsable R&D hardware d'Eco-Compteur (Lannion), qui mesure la fréquentation piétons et vélos pour les collectivités : né d'une carte électronique dans un pot de confiture sur un sentier, l'entreprise revendique 150 salariés et 30 000 compteurs installés.
  • Grille de lecture d'un système IoT par ses contraintes : volume de données, coûts (composants, batteries lithium, data selon le pays), dimensions, durée de vie, environnement, alimentation, installation, déploiement, maintenance, supervision, interopérabilité, sécurité.
  • Choix du cellulaire pour couvrir 55 pays, de la 2G jusqu'au LTE-M et NB-IoT ; leçon de maturité : les opérateurs ont eu 4 ans de retard sur LTE-M, et les premières stacks étaient boguées, ce qui a bloqué le remplacement des produits 3G.
  • Produits étanches, parfois immergés des semaines ou intégrés par les clients dans des boîtes métalliques ; installateurs peu techniques guidés par une appli mobile qui vérifie la transmission sur site.
  • Supervision indispensable : « un produit IoT qui ne peut plus communiquer […] c'est un produit qui est mort » ; maintenance à distance limitée par des connexions 2 à 4 fois par jour.
  • Sécurité prise au sérieux « depuis 2 ans », sous la pression du Cyber Resilience Act ; pistes d'avenir : LwM2M (sécurité, compression, modèle de données) et transmission satellite pour les zones blanches.

Conférence▶ vidéo + transcript

Retour d'expérience sur l'utilisation de Rust/Linux dans une borne de charge véhicule électrique

Fulup Ar Foll — IoT.bzh, Valentin Geffroy — IoT.bzh

  • Projet open source Tux-EVSE d'IoT.bzh (Lorient) : une borne dialogue avec la voiture (IEC, puis ISO 15118 en XML binaire, « super galère »), avec le cloud (OCPP, du JSON en WebSocket) et avec le réseau électrique (compteur Linky, planification de charge).
  • Une borne est une belle passerelle pour un attaquant : réseau d'énergie, maison et opérateur de mobilité à la fois ; plug and charge, services à valeur ajoutée en IPv6 et accès physique multiplient les surfaces d'attaque.
  • Réponses : code signé et vérifié au boot et à chaque mise à jour, contrôle d'accès obligatoire, namespaces et cgroups, chiffrement complet ; le modèle distribué (sécurité entre îlots) préféré au « château fort ».
  • Architecture asymétrique : Linux sur Cortex-A, Zephyr sur Cortex-M via OpenAMP pour le temps réel et la sûreté (détection de branchement, verrou de prise), car « 15 000 lignes » se certifient mieux que Linux.
  • Bilan sur Rust, opinion assumée de Fulup Ar Foll : analyse statique mémoire « hors du commun », meilleur code à salaire égal qu'en C++ ; mais packaging « l'enfer », pas de compatibilité binaire entre versions, dépendances en cascade, async difficile ; plus d'un an pour l'intégrer à la CI. Verdict : « bon mais pas exceptionnel ».
  • Valentin Geffroy montre le matériel (BeaglePlay, Raspberry Pi, modem PLC, écran LVGL, LoRaWAN) et la chaîne de packaging redpesk Factory ; code et slides publiés, démonstration du matériel proposée à la pause déjeuner.

Lightning talk▶ vidéo + transcript

Quickie : combiner IoT et software pour réduire l'impact carbone des déchets

Aurélien Conte — Heyliot, Tony Chouteau — Mobil-inn

  • Deux entreprises intégrées : Heyliot fournit une sonde de remplissage laser (mesure jusqu'à 4 m, installation en moins de 5 minutes, autonomie annoncée de 5 à 8 ans) pour les points d'apport volontaire ; Mobil-inn édite iSmartCollect, logiciel de gestion de parc et de tournées.
  • Données remontées via Sigfox, LoRa ou LTE-M (en secours quand les autres réseaux manquent), reçues en callbacks HTTP, décodées et exposées par API ; synchronisation bidirectionnelle du parc entre les deux sociétés pour rester invisible au client.
  • Côté terrain : tablette à gros boutons pour des agents gantés qui collectent la nuit, saisie manuelle du remplissage si un point n'est pas sondé, création de tournées « en à peine 5 clics » à partir d'un seuil de remplissage.
  • Mobil-inn filtre les mesures (valeurs constantes, pics aberrants) pour ne garder que ce qui sert à des utilisateurs « pas forcément informaticiens ».
  • Cas cités : Pays de Montbéliard (environ 1 400 sondes) et une collecte de textiles près de Bordeaux (plus de 850 sondes), où le remplissage moyen avant collecte serait passé de moins de la moitié à près de 80 % (chiffres des speakers).

Conférence▶ vidéo + transcript

Comment connecter efficacement les applications d'IA dans les systèmes IoT industriels, de l'Edge au Cloud

Thomas Leseney — Netvolt

  • Constat : l'IoT industriel produit les données, l'IA s'en nourrit, mais entre une éolienne isolée et un cluster GPU dans le cloud, le chemin est « tortueux » ; les sites doivent continuer à fonctionner sans connectivité.
  • La pyramide hiérarchique des SI industriels des années 80 n'est pas faite pour l'IoT ; les intégrations point à point finissent en « gros tas de spaghetti ».
  • Démarche : découplage spatial (pub/sub, MQTT), puis temporel (flux persistés type Kafka), cache pour redescendre les modèles (type Redis), service mesh pour des milliers de services d'inférence ; mais 4 à 6 technologies, c'est trop de formation, de surface d'attaque et de clusters pour un industriel.
  • Choix de Netvolt : NATS (CNCF, écrit en Go, un binaire d'environ 16 Mo sans dépendance) qui couvre pub/sub, request/reply, flux persistés (JetStream), clé-valeur et exécution de charges ; sécurité zero trust décentralisée.
  • Atout clé : les leaf nodes, qui relient un site local à un cluster sans en faire partie, avec stockage local et resynchronisation automatique, y compris vers des partenaires externes.
  • Démo : reconnaissance de visage servie en local, avec bascule transparente vers une instance cloud aux États-Unis quand le service local est coupé (latence visible), puis tirage au sort d'un t-shirt via un microservice dans le navigateur.

Conférence▶ vidéo + transcript

Le réseau LoRa de Rennes Métropole, un réseau pionnier dont l'histoire ne fait que commencer

Pierre Renault — Rennes Ville et Métropole

  • Huit ans de retour d'expérience d'une collectivité : expérimentation en 2015, réseau en 2016 sur la gestion des bâtiments, passage à l'échelle métropolitaine vers 2019-2020 avec la télérelève des points d'apport volontaire.
  • Aujourd'hui environ 70 antennes, plus de 4 000 capteurs, 25 cas d'usage (déchets, énergie, îlots de chaleur avec 120 stations du CNRS et Rennes 2, CO2 dans les écoles) ; réseau public, mutualisé et réservé à l'intérêt général, piloté en interne par deux personnes à temps partiel.
  • Pourquoi un réseau propre plutôt qu'un opérateur : maîtrise de l'infrastructure, indépendance technologique, choix de capteurs, et abonnements évités qui ont convaincu la direction des finances (coût annoncé d'environ 400 000 € par an).
  • Leçons : les cartes de couverture théoriques « ça suffit jamais », il faut aller sur le terrain ; pas de déploiement industriel possible en gestion technique des bâtiments, « chaque bâtiment est différent ».
  • Changement d'échelle à venir : pilotage de l'éclairage public, télérelève de l'eau (jusqu'à 240 000 compteurs à terme), passage visé de 5 000 à 60 000 capteurs.
  • Points durs : un cadre juridique calqué sur la fibre, inadapté ; la gouvernance d'un réseau mutualisé ; la propriété des données ; la cybersécurité (CRA, NIS 2). Refus assumé d'usages sensibles (hygrométrie du Musée de Bretagne, sol connecté en Ehpad).

Conférence▶ vidéo + transcript

Comment la domotique peut-elle vous aider à adopter une approche plus écoresponsable tout en réduisant vos factures ?

Pierre Andrieux — Capgemini

  • Cas personnel plutôt que client, pour éviter d'anonymiser : la domotique comme porte d'entrée la plus accessible de l'IoT ; à main levée, une partie seulement de la salle en fait chez elle.
  • Usages : détecter une fuite d'eau pendant les vacances (vécu par le speaker), connaître le talon de consommation électrique, sécurité, confort, accessibilité ; ordres de grandeur cités : environ 150 L d'eau par jour et par personne, 2 223 kWh d'électricité.
  • Home Assistant préféré à Jeedom, ThingsBoard, openHAB ou Domoticz pour sa communauté (Python, applis natives, mises à jour quasi hebdomadaires) ; installer l'OS plutôt que la version conteneur, dont un collègue regrette les mises à jour.
  • Limite relevée : base SQL et historique d'environ 30 jours par défaut, d'où l'export vers InfluxDB pour les séries temporelles.
  • Installation : vieille Surface Pro de 2014, dongle Zigbee Sonoff et module Lixee branché sur le Linky pour la consommation en temps réel ; démo en direct du dashboard, des groupes de volets, des automatisations et du module énergie (part d'électricité bas carbone).
  • Prochaines étapes : télérelève du compteur d'eau, contribution au projet, modèle de ML pour reconnaître les appareils à leur pic de consommation.

Conférence▶ vidéo + transcript

Pourquoi votre IoT mérite mieux que Grafana

Pierre Papin — SenX, Xavier Marin — SenX (absent, malade)

  • Pierre Papin présente seul, Xavier Marin, créateur de Discovery, étant malade. Point de départ : « une poubelle ou un avion, c'est des time series », et SQL n'est pas fait pour le traitement du signal ; d'où Warp 10 et son langage WarpScript (environ 1 300 fonctions).
  • Reproches à Grafana pour l'IoT : plugins qui cassent avec les API, une requête par tuile, impossibilité de masquer ce qui va bien, intégration dans un autre site limitée à une iframe.
  • Discovery : web components open source, « vrai dashboard as code » : le dashboard est généré par un script, ce qui permet boucles et conditions (un carré vert si tout va bien, des courbes sinon).
  • Démo dans VS Code sur la sandbox Warp 10 : 520 000 points réduits à 10 000 par LTTB pour garder la forme de la courbe, puis une tuile par série générée en boucle, avec une seule requête pour toutes les tuiles.
  • Les tuiles communiquent par événements typés (variables, styles, SVG, popups), ce qui évite de rafraîchir tout le dashboard ; démos d'une barrière SVG animée et d'un dashboard générant un autre dashboard.
  • Autres nouveautés évoquées : format d'archivage HFiles (utilisé par Clever Cloud selon le speaker) et un agent conversationnel pour séries temporelles ; offre SaaS en marque blanche.

Sessions sans retour trouvé (3)

  • Où est Charlie ? (dans mes données IoT géo-référencées) (Benoit Rouxel et Erwan Duval, Thales ; pas de vidéo)
  • Mot d'introduction (organisateurs, non filmé)
  • Le mot de la fin (organisateurs, non filmé)

Sources