Note de transparence
ComiPi accompagne SISKIA sur la structuration technique et la reproductibilité internationale. En tant que président de l'association, je ne peux pas prétendre à une neutralité totale sur ce projet — c'est pourquoi les chiffres de cet article sont explicitement flaggés là où ils restent à confirmer sur des séries longues.
Le problème humain : une fenêtre de quelques minutes.
Le monoxyde de carbone ne s'annonce pas. Il ne sent rien, il ne se voit pas, il tue en quelques dizaines de minutes dans une pièce mal ventilée. Un incendie naissant dans un local associatif non surveillé peut parcourir un bâtiment en moins de dix minutes avant qu'une alarme soit déclenchée — si tant est qu'il y en ait une. Une dérive thermique dans un data center ou une salle serveur, la nuit, un week-end, peut coûter des semaines de reconstruction.
Ce n'est pas un problème de technologie. La technologie pour détecter tout ça existe depuis longtemps. C'est un problème d'accès. Les solutions commerciales de surveillance environnementale déployées dans les bâtiments professionnels coûtent entre 300 et 500 € par point de mesure, parfois davantage quand on ajoute les abonnements cloud, les contrats de maintenance, et les certifications propriétaires. Pour une PME ou un service technique d'une collectivité, ça reste gérable. Pour une association qui gère un centre social, une école communautaire, ou un entrepôt de stockage alimentaire au fin fond d'une région éloignée — c'est simplement hors de portée.
C'est le point de départ de SISKIA. Pas de créer une "solution de surveillance connectée" de plus. Créer un dispositif que n'importe quelle organisation dans le monde peut reproduire avec des composants commandés localement, pour moins de 50 €, avec une documentation suffisamment claire pour être suivie sans ingénieur sur place. La question que ComiPi a été missionné à résoudre : quelle stack de composants rend ça possible ?
Pourquoi des composants standards, pas du custom.
Le réflexe classique dans ce genre de projet, c'est de concevoir un circuit imprimé propriétaire. Ça permet d'optimiser la consommation, de miniaturiser, d'intégrer exactement ce dont on a besoin. Sur un projet avec un budget R&D, une chaîne d'approvisionnement maîtrisée et une équipe électronique, ça a du sens.
Sur un projet conçu pour être reproductible par une association marocaine, sénégalaise ou péruvienne avec 50 € et une connexion internet, ça n'en a pas. Le PCB custom crée trois problèmes immédiatement : les coûts de fabrication en petite série sont prohibitifs, la chaîne d'approvisionnement des composants spécifiques est fragile, et dès qu'un composant est en rupture ou discontinué, le projet meurt faute de pouvoir le remplacer. La documentation devient un actif qui se périme.
L'obsession COTS
COTS — Components Off The Shelf — c'est l'obsession centrale de l'architecture SISKIA. Chaque composant retenu doit pouvoir être commandé sur AliExpress, chez un distributeur électronique local, ou via les chaînes régionales d'approvisionnement. S'il disparaît du catalogue, son remplaçant doit être interchangeable avec une modification de firmware minimale. La reproductibilité internationale n'est pas une option — c'est le critère de sélection numéro un.
ComiPi a donc posé une règle simple pour la sélection : chaque composant retenu doit exister sur au moins trois fournisseurs indépendants, avoir une documentation publique complète, être présent depuis au moins trois ans dans les catalogues, et avoir une communauté active (tutoriels, bibliothèques, exemples de code). Ce filtre a éliminé une partie des capteurs les plus précis et les plus intéressants techniquement — au profit de composants moins exotiques, mais durables et remplaçables.
La deuxième règle : le firmware doit être en open source, documenté, avec une procédure d'installation que quelqu'un qui n'a jamais fait de développement embarqué peut suivre en une après-midi. C'est ça qui détermine si un dispositif est réellement reproductible ou s'il reste un prototype de labo.
La stack capteur : composant par composant.
Voici les choix retenus et ce qui les justifie. Les prix sont indicatifs, relevés courant 2025-2026 sur AliExpress et distributeurs équivalents. [FLAG prix] : volatilité ~15 % selon les approvisionnements et les taux de change — vérifier avant achat.
MCU — ESP32-S3
Le microcontrôleur central, c'est l'ESP32-S3 d'Espressif. [FLAG prix] ~5 € en module breakout. Pourquoi lui et pas un Arduino, un STM32, ou un nRF52 ? Trois raisons. D'abord, le Wi-Fi et le Bluetooth LE sont intégrés nativement — ce qui couvre les scénarios de déploiement en zone urbaine ou dans un bâtiment avec réseau existant, sans composant radio additionnel. Ensuite, l'écosystème ESP-IDF / Arduino ESP32 est probablement le plus documenté du marché en dehors de l'Arduino classique — des milliers d'exemples, des bibliothèques maintenues, une communauté active dans pratiquement toutes les langues. Enfin, la disponibilité : l'ESP32 existe dans des dizaines de variantes de modules, fabriqué par Espressif et des tiers, présent partout dans le monde depuis 2016.
La variante S3 apporte un processeur dual-core cadencé à 240 MHz, une meilleure sécurité hardware (flash chiffré, secure boot), et des performances suffisantes pour faire tourner une couche TLS sans sacrifier l'autonomie. Pour un capteur qui doit potentiellement transmettre sur une connexion MQTT sécurisée, c'est structurant.
CO — MQ-7
La détection de monoxyde de carbone repose sur le MQ-7. [FLAG prix] ~3 €. Ce capteur électrochimique est le standard de facto pour la détection CO dans les projets maker et industriels légers depuis plus de dix ans. Sa courbe de réponse est documentée, ses seuils de détection sont cohérents avec les normes EN 50291 (alarme résidentielle CO), et les bibliothèques Arduino sont stables.
Le MQ-7 a un défaut connu : il nécessite un cycle de chauffe de 60 secondes à 5V avant de donner des mesures fiables, suivi d'un refroidissement à 1.4V. Ce cycle doit être implémenté correctement dans le firmware, sinon les lectures sont fausses. C'est précisément le genre de friction que nous avons documentée — voir la section "Ce qui a frotté" plus bas.
Température / Humidité / COV — BME680
Pour la mesure environnementale multi-paramètre, le BME680 de Bosch est retenu. [FLAG prix] ~10 €. Il mesure en un seul composant la température, l'humidité, la pression atmosphérique, et un indice de qualité d'air basé sur les composés organiques volatils (COV). Ce dernier paramètre est particulièrement utile pour détecter des fumées de départ d'incendie ou des émanations chimiques avant qu'elles atteignent des seuils dangereux.
La bibliothèque BSEC de Bosch gère le calibrage automatique de l'indice IAQ (Indoor Air Quality) sur 28 jours d'apprentissage. C'est un avantage réel : le capteur s'adapte à l'environnement de déploiement plutôt que de donner des valeurs absolues qui varieraient d'un bâtiment à l'autre. La contrepartie, c'est que les premières semaines de déploiement, les seuils d'alerte doivent être moins stricts le temps que le calibrage converge.
Matrice thermique IR — MLX90640
Le MLX90640 de Melexis est le composant le plus cher de la stack. [FLAG prix] ~25 €. C'est une matrice de 32×24 pixels thermiques qui permet de détecter des points chauds anormaux — un départ d'incendie, une surchauffe électrique, un équipement en panne — sans contact et sans visibilité directe dans l'obscurité. Sa résolution thermique de 0,1 °C est largement suffisante pour des applications de détection d'anomalie.
Ce composant n'est pas indispensable dans tous les scénarios. Un capteur SISKIA sans MLX90640 descend sous les 25 € et reste pertinent pour la surveillance qualité d'air seule. Le MLX90640 est le module "incendie précoce" — il est intégré sur les unités déployées dans des environnements à risque électrique ou thermique spécifique. La modularité de la stack permet ce choix sans refonte hardware.
Radio LoRaWAN — SX1276 868 MHz
Dans les scénarios de déploiement hors Wi-Fi — bâtiments isolés, zones rurales, déploiements sans infrastructure réseau existante — la radio LoRaWAN est indispensable. Le module SX1276 (ou équivalents Ra-02, RFM95W) sur la fréquence 868 MHz EU est retenu. [FLAG prix] ~8 €. La portée théorique en zone dégagée dépasse 5 km ; en milieu urbain, 500 m à 1 km sont courants selon l'obstruction. La consommation en transmission est de l'ordre de 40 mA sur des durées de quelques secondes — compatible avec une alimentation solaire.
Ce module est utilisé en complément ou en remplacement du Wi-Fi selon le scénario, pas systématiquement avec lui. L'architecture firmware prévoit les deux modes, sélectionnables par configuration au déploiement. Le lien entre les capteurs LoRaWAN et l'infrastructure de collecte est couvert dans l'article sur la gateway LoRaWAN SISKIA.
Alimentation — LiFePO4 + solaire
L'alimentation est probablement le sujet le plus critique pour la reproductibilité terrain. Une batterie lithium-ion classique 18650 tient 2-3 ans en cyclage quotidien dans des conditions de chaleur. Dans un boîtier IP67 exposé au soleil dans une région chaude — conditions typiques d'un déploiement au Maroc ou au Sénégal — la dégradation peut être bien plus rapide.
Le choix retenu est la chimie LiFePO4 (lithium fer phosphate) en format 18650. [FLAG prix] ~4 € la cellule. Cette chimie tolère les cycles charge/décharge profonds, supporte les températures élevées bien mieux que le Li-Ion standard, et présente une sécurité intrinsèquement meilleure (pas de risque thermique en cas de surcharge). Couplée à un panneau solaire 1-2 W et un module MPPT (Maximum Power Point Tracking, [FLAG prix] ~5-8 €), le système est théoriquement autonome en zone avec ensoleillement minimal. [FLAG autonomie] : l'objectif de 5 à 10 ans est basé sur les cycles LiFePO4 et des calculs de consommation en mode deep sleep — à confirmer sur prototypes long terme.
Boîtier — IP67
Deux options selon le contexte de déploiement : un boîtier industriel COTS IP67 standard (format Hammond ou équivalent, [FLAG prix] ~5-8 €), ou un boîtier imprimé en 3D avec joint torique, pour les structures qui ont accès à une imprimante 3D. Les fichiers STL sont publics dans le dépôt SISKIA. L'option COTS est recommandée pour les déploiements critiques — la reproductibilité par impression 3D reste dépendante de la qualité d'impression et du matériau choisi (PETG ou ASA pour la résistance UV).
Le BOM public : récapitulatif et justification.
La BOM complète est publique sur le dépôt SISKIA. Voici le récapitulatif des composants principaux. Tous les prix sont indicatifs [FLAG prix] et à vérifier au moment de la commande.
Ces fourchettes correspondent à une réalité de commande : les prix AliExpress varient selon les vendeurs, les lots et les taux de change. La BOM publique du projet SISKIA contient les liens de commande et les alternatives vérifiées par l'équipe.
Pourquoi la BOM publique est centrale
Une documentation sans BOM publique, c'est un projet semi-reproductible. L'organisation qui veut répliquer le dispositif doit chercher elle-même les composants équivalents, espérer qu'ils sont compatibles, et tester. Sur un projet de sécurité incendie ou de détection de gaz, c'est une friction qui peut bloquer le déploiement complètement, ou pire, conduire à des substitutions non validées.
La BOM publique SISKIA liste les composants validés, leurs équivalents testés, les points de vigilance par composant, et les sources d'approvisionnement régionales connues. C'est le document central pour qu'une organisation au Maroc, au Sénégal ou au Pérou puisse commander localement sans avoir à refaire le chemin qu'on a fait.
Ce qui a frotté.
Un article qui ne dit que ce qui marche est un article publicitaire. Voici les vrais points de friction.
Le cycle de chauffe du MQ-7. C'est le problème le plus classique et le plus sous-documenté. Le capteur MQ-7 nécessite un cycle de chauffe précis : 60 secondes à 5V, puis 90 secondes à 1,4V, en boucle, pour fonctionner correctement. Si ce cycle n'est pas implémenté dans le firmware — ou s'il est approximatif — les lectures de CO sont fausses, parfois de façon spectaculaire. Plusieurs prototypes initiaux donnaient des alarmes CO sur des environnements propres uniquement parce que la tension de refroidissement n'était pas assez précise. La solution : un régulateur dédié et une implémentation rigoureuse du cycle dans le firmware, documentée pas à pas.
L'autonomie réelle vs théorique. Les calculs de consommation en mode deep sleep donnent des durées d'autonomie qui font rêver. Sur le papier, avec un ESP32-S3 en sommeil profond à 20 µA, une batterie LiFePO4 2000 mAh, et une remontée de mesure toutes les 15 minutes, on calcule des années d'autonomie. La réalité sur prototype : les réveils fréquents, le cycle de chauffe du MQ-7 (qui consomme environ 180 mW pendant 60 secondes), et les transmissions radio grignotent significativement. [FLAG autonomie] L'objectif 5-10 ans avec solaire reste plausible mais n'a pas encore été validé sur des déploiements longue durée. Sur des prototypes tournant depuis plusieurs mois, la consommation réelle est dans la fourchette attendue — mais les projections longues sont encore à confirmer.
Le calibrage des seuils d'alerte. Fixer un seuil d'alerte CO à 50 ppm est une chose en théorie. En déploiement réel, dans un local avec une cuisinière à gaz, un seuil trop bas déclenche des fausses alarmes sur la simple cuisson. Le calibrage des seuils par environnement de déploiement est une étape obligatoire que la documentation doit expliciter — et que les équipes qui répliquent le dispositif doivent effectuer localement. Ce n'est pas un défaut du composant, c'est une réalité de la mesure environnementale : les seuils absolus ne remplacent pas la contextualisation.
La connectivité LoRa en intérieur. Les portées théoriques du SX1276 sont mesurées en zone dégagée. Dans un bâtiment avec des murs béton épais, les performances chutent rapidement. Le placement des capteurs par rapport aux gateways est un paramètre de déploiement critique — la documentation inclut maintenant un protocole de test de signal avant installation définitive.
Ce que ça change pour SISKIA — et au-delà.
Ce choix de stack COTS a des conséquences concrètes qui dépassent le seul projet SISKIA.
Pour SISKIA d'abord : l'organisation peut déployer des capteurs sans dépendre d'une chaîne d'approvisionnement centralisée. Une association partenaire au Maroc peut commander les composants chez un distributeur régional ou directement depuis AliExpress avec les références de la BOM. Elle peut assembler le dispositif en suivant la documentation sans faire appel à une compétence électronique avancée. Si un composant tombe en panne, elle peut le remplacer elle-même. Ce n'est pas la même chose que de dépendre d'un prestataire unique pour envoyer un technicien.
Pour ComiPi, ce projet illustre une conviction de fond : la valeur ne vient pas de la complexité du composant, mais de la qualité de la documentation et de la sobriété de l'architecture. Un capteur à 400 € avec une documentation propriétaire crée une dépendance. Un capteur à 50 € avec une BOM publique, des schémas ouverts et un firmware documenté crée de l'autonomie. Ce n'est pas seulement une question d'argent — c'est une question de qui garde le contrôle.
La prochaine étape logique est la gateway LoRaWAN : le point de collecte qui agrège les mesures de plusieurs capteurs SISKIA et les remonte vers la plateforme de visualisation. La gateway pose d'autres questions d'architecture — sélection du protocole de remontée, hébergement, disponibilité, et là encore reproductibilité pour des structures sans budget DSI. C'est l'objet de l'article suivant du cluster SISKIA : la gateway LoRaWAN, de la réception au dashboard.
Reproductibilité internationale — la vraie métrique
On mesure souvent le succès d'un projet hardware au nombre d'unités déployées. Pour SISKIA, la métrique qui compte est différente : combien d'organisations indépendantes ont reproduit le dispositif sans notre aide directe ? C'est ça, la reproductibilité réelle. La BOM publique, la documentation, les procédures de test — tout est conçu pour maximiser cette métrique, pas le nombre de capteurs que nous-mêmes déployons.
Dans le même cluster
- SISKIA : du proto au dispositif reproductibleL'article pillar du cluster — comment ComiPi a structuré la stratégie et la méthode de SISKIA, de l'intention à la reproductibilité internationale.
- La gateway LoRaWAN SISKIALa suite logique de cet article : comment les capteurs remontent leurs données, quelle architecture de collecte, et les mêmes arbitrages COTS appliqués à la couche réseau.
- Manifeste : de John Deere 1999 à ComiPi 2026La conviction de fond qui sous-tend SISKIA : un problème résolu est rarement uniquement le sien. Il est presque toujours réplicable à d'autres territoires.
- Dolibarr moche + app UX : l'architecture qui tient en 2026Le même raisonnement COTS appliqué à la stack logicielle — socle structurant + couche UX sur mesure, sans lock-in.
- siskia.org — le projetLe site de l'association, la BOM publique, et les ressources de déploiement.
Vous avez un projet similaire ?
Parlons stack.
Si vous construisez un dispositif IoT à contrainte de coût et de reproductibilité — pour une asso, une collectivité, ou une PME — les arbitrages SISKIA peuvent nourrir votre propre démarche. Un premier échange ne coûte rien.
La suite du cluster SISKIA
La gateway LoRaWAN
Capteurs déployés, données captées — maintenant il faut les collecter, les agréger, et les rendre lisibles. La prochaine étape architecturale.