Statut — phase conception
Ce que nous décrivons ici n'est pas encore volant. Nous sommes en phase de conception : architecture définie, briques techniques identifiées, contraintes réglementaires cartographiées, budget estimé. Rien n'a décollé. Ce document est un artefact de travail transparent — pas un produit fini. Nous le publions parce que la méthode de conception est déjà utile, et parce que SISKIA n'a aucune raison de cacher ce qui est en cours.
Après le capteur, il reste une question : qu'est-ce qui s'est vraiment passé ?
Le capteur de détection SISKIA fait bien son travail : il mesure, il qualifie, il remonte une alerte quand la signature sort des seuils. Mais une alerte, ce n'est pas une certitude. C'est une probabilité. Et une probabilité, dans un contexte de surveillance environnementale ou de sécurité de site isolé, ça ne suffit pas à déclencher une intervention humaine coûteuse — ni à justifier l'inaction.
Le problème structurel est là : entre le signal du capteur et la décision humaine, il y a un gap. Un angle mort. La signature est anormale — mais est-ce une intrusion réelle, un animal, une panne de capteur, un effet météo ? Pour répondre à cette question depuis un poste de supervision distant, il faut des yeux sur place. Des yeux disponibles en permanence, en quelques secondes, sans coût d'exploitation prohibitif.
C'est exactement le rôle que nous concevons pour le drone dans l'architecture SISKIA. Il n'est pas là pour remplacer l'humain dans la décision. Il est là pour fournir à l'humain la confirmation visuelle et thermique qui lui permet de décider — intervenir, ignorer, escalader — avec des données réelles plutôt qu'avec une probabilité. La chaîne complète : capteur → probabilité → drone → certitude → décision humaine.
Pourquoi un drone et pas une caméra fixe ?
La caméra fixe est moins chère à l'installation et plus simple à opérer. Mais elle couvre un champ fixe, elle est visible (et donc contournable), elle ne peut pas suivre un déplacement, et elle ne peut pas lever l'ambiguïté quand la signature vient d'un angle mort. Le drone couvre la zone à la demande, s'approche du point d'intérêt, lit thermiquement la signature, revient. Sur un site isolé de plusieurs hectares, c'est le seul dispositif autonome qui donne réellement une image de situation. Le coût d'acquisition et de maintenance reste le frein principal — c'est précisément ce que nous attaquons.
L'architecture que ComiPi a imaginée : du capteur au retour station
Voici la séquence telle que nous la concevons. Chaque maillon est discuté plus bas ; ici, on pose le flux complet pour que l'architecture soit lisible d'un coup.
Un capteur terrain détecte une signature anormale — vibration, franchissement de seuil magnétique, signature acoustique, chaleur. Il émet une trame LoRaWAN. La gateway LoRaWAN SISKIA reçoit la trame et la transmet au serveur réseau ChirpStack, auto-hébergé. ChirpStack évalue l'alerte : si elle dépasse le seuil de déclenchement configuré, il appelle un endpoint HTTP du serveur de contrôle du drone. Ce serveur — un service Python léger, auto-hébergé sur le même VPS ou sur un Raspberry Pi de la station — envoie un ordre de décollage au contrôleur de vol via MAVLink. Le drone décolle, suit un plan de vol pré-calculé vers le point d'intérêt, effectue sa reconnaissance visuelle et thermique, transmet en temps réel via 4G ou via LoRa télémétrie selon la couverture, puis retourne automatiquement à sa station de base. En fin de mission, il se pose et enclenche la recharge solaire.
Le maillon le plus fragile : la décision de décoller
Entre l'alerte ChirpStack et l'ordre de décollage, nous prévoyons une logique de validation minimale : l'alerte doit être confirmée par au moins deux capteurs ou répétée sur trois trames consécutives avant de déclencher le vol. L'objectif est d'éviter qu'une alarme parasite sur un capteur défaillant envoie le drone dans un vol inutile — ou pire, dans une condition météo dégradée. Cette logique de confirmation est codée dans le service de contrôle, pas dans ChirpStack. Elle est versionnée, testable, modifiable sans toucher à l'infrastructure réseau.
Ce que nous ne voulons pas : une chaîne où la logique de décision est enfouie dans la configuration d'un outil tiers non auditable. Tout ce qui est orchestration, ComiPi le code. La règle s'applique ici exactement comme dans l'architecture ComiPi ERP : maîtrise du flux, traçabilité de chaque décision, transmission technique possible à l'équipe SISKIA.
Les briques techniques choisies — COTS, justifiées une par une
Chaque composant de cette architecture a été sélectionné selon trois critères : disponibilité en COTS (composants standards du commerce), documentation communautaire suffisante pour une intégration autonome, et coût compatible avec un budget association. Voici les choix retenus à ce stade de conception.
Contrôleur de vol
Nous retenons le Pixhawk Cube Orange+ associé au firmware ArduPilot (ArduCopter pour multirotor). C'est l'ensemble le plus documenté de l'open hardware aéronautique : plusieurs millions de vols enregistrés dans les logs communautaires, une base de développeurs active, une compatibilité MAVLink complète, et un écosystème de ground stations open source (Mission Planner, QGroundControl) qui permet de définir les plans de vol, les retours d'urgence, les zones d'exclusion. ArduPilot supporte nativement le mode Guided (plan de vol déclenché via MAVLink depuis un service externe) — c'est exactement ce dont nous avons besoin pour piloter le drone depuis ChirpStack.
Alternative envisagée : une base DJI hackable (Mini 3 ou M30 en mode DJI SDK). Nous l'avons écartée pour deux raisons. Première raison : la dépendance à DJI Cloud et aux serveurs DJI pour l'activation, ce qui crée un point de défaillance externe incompatible avec nos contraintes de souveraineté. Deuxième raison : le SDK DJI Mobile impose une application Android ou iOS comme intermédiaire — pas d'intégration propre avec un service Python auto-hébergé.
Charge utile — imagerie thermique
Pour la caméra thermique, nous partons sur le FLIR Lepton 3.5 (160×120 pixels, 8,6 mm de focale, FOV 57°). C'est le module thermique le moins cher disponible avec une interface SPI directe vers Raspberry Pi ou ESP32 — moins de 200 € en direct sur le marché des modules COTS. ESTIMATION La résolution 160×120 est basse, ce qui est assumé : à 30-50 mètres d'altitude, elle est suffisante pour distinguer une signature humaine ou animale d'une anomalie technique. Pour une identification fine (plaque d'immatriculation, visage), c'est insuffisant — mais ce n'est pas l'objectif de SISKIA. L'objectif est la qualification de signature, pas l'identification forensique.
Pour l'imagerie RGB, nous intégrons une caméra 4K légère compatible Raspberry Pi Camera Module 3 ou équivalent Sony IMX477. Poids total de la charge utile estimé à moins de 120 grammes. ESTIMATION
Navigation et positionnement
Nous ciblons un GPS RTK avec précision sub-décimétrique (objectif : moins de 10 cm) pour garantir que le drone se positionne précisément au-dessus du point d'intérêt défini par les coordonnées GPS du capteur déclencheur. ESTIMATION précision Un module Ardusimple simpleRTK2B + antenne patch coûte environ 200 € et s'intègre directement dans l'écosystème ArduPilot via UART. En cas de perte du signal RTK (nuage, obstruction), le système bascule automatiquement sur GPS standard et maintient le vol avec une précision dégradée — préférable à un retour d'urgence immédiat dans la plupart des scénarios de surveillance.
La télémétrie sol-air passe par un module LoRa 433 MHz (RFD900x ou équivalent) pour la liaison de contrôle à longue portée, avec un canal 4G en fallback via un module SIM7600 intégré à la station de base. La LoRa télémétrie n'est pas à confondre avec le réseau LoRaWAN des capteurs : c'est un lien point à point dédié au protocole MAVLink, sans infrastructure réseau intermédiaire.
La station de base
C'est le composant le plus coûteux de l'ensemble et celui qui justifie le mieux l'écart avec les solutions commerciales. Un DJI Dock 2 coûte autour de 50 000 € à l'installation. ESTIMATION prix DJI Dock marché FR 2026 Notre conception vise une station entre 3 000 et 5 000 € tout comprisESTIMATION, assemblée sur la base d'une box étanche IP66, d'un système de recharge par panneau solaire (panneau 100 Wc + batterie LiFePO4 100 Ah), d'un mécanisme d'ouverture motorisée de trappe simple, et d'un Raspberry Pi 4 comme cerveau local pour le service de contrôle et le stockage des données de vol. La station tient en autonomie complète sur site isolé sans alimentation secteur.
Ce n'est pas un produit fini. C'est un assemblage de COTS bien documentés, pensé pour être reproductible par une association avec des compétences de base en électronique et en menuiserie. La BOM sera publique, comme pour le reste des dispositifs SISKIA.
Les obstacles réels : DGAC, météo, services de secours
Nous ne nous racontons pas d'histoires sur les frictions réglementaires et opérationnelles. Elles sont réelles, substantielles, et elles expliquent en partie pourquoi personne n'a encore déployé ce type de dispositif à grande échelle sur le marché associatif.
La réglementation DGAC et le régime BVLOS
En France, les vols de drones au-delà de la ligne de vue (BVLOS — Beyond Visual Line of Sight) sont soumis à une procédure d'autorisation spécifique de la DGAC, en application du règlement UE 2019/947 et de ses amendements. À date, les opérations BVLOS répétées et automatisées sur site fixe relèvent du scénario U-Space ou de l'autorisation spécifique STS-02 étendue — aucune des deux voies n'est triviale pour une petite association.
Ce que cela signifie concrètement : nous ne pourrons pas déployer ce drone en opérations réelles sans une phase de cadrage réglementaire avec un prestataire spécialisé DGAC, probablement une expérimentation sur site privé d'abord, et une concertation avec la préfecture et les services de sécurité civile compétents pour la zone. Ce n'est pas impossible — d'autres acteurs l'ont fait, notamment dans le domaine de la surveillance de forêts et d'infrastructures critiques. Mais c'est un investissement en temps et en dossiers administratifs qui dépasse largement le temps de construction du matériel.
Nous considérons la réglementation DGAC comme un frein sérieux à court terme, et non comme un obstacle définitif. La tendance européenne est à la clarification progressive des cas d'usage BVLOS pour des scénarios de service public ou associatif — les textes bougent. Nous suivons.
La météo
Un drone multirotor COTS de moins de 2 kg n'opère pas dans n'importe quelle condition. Vent supérieur à 10-12 m/s, pluie, givre : autant de conditions dans lesquelles un décollage automatique non supervisé est dangereux pour le matériel et pour l'environnement du site. La station de base intégrera un module météo local (anémomètre, thermomètre, hygrométre) dont les seuils sont vérifiés avant tout ordre de décollage. Si les conditions ne sont pas réunies, le système consigne l'alerte et notifie l'opérateur humain en attente — le drone ne décolle pas. Cette limitation n'est pas contournable avec du matériel COTS dans ce budget. Elle est assumée et documentée.
L'intégration avec les services de secours
Un drone qui décolle automatiquement sur un site surveille peut entrer en conflit avec des hélicoptères ou des drones des services de sécurité déjà déployés sur zone. Ce n'est pas un scénario improbable pour les sites SISKIA — certains sont des zones naturelles sensibles avec intervention fréquente de la sécurité civile ou des pompiers. L'intégration avec les systèmes de déconfliction de trafic aérien (U-Space en devenir, ou simplement notification NOTAM) est un chantier que nous n'avons pas encore ouvert. C'est une dépendance externe que nous ne pouvons pas résoudre seuls.
Pourquoi on continue malgré le stade conception
La question mérite d'être posée directement : si les obstacles réglementaires et opérationnels sont aussi sérieux, pourquoi investir du temps de conception maintenant ? Pourquoi ne pas attendre que le cadre BVLOS se stabilise, que les coûts des modules thermiques baissent encore, que quelqu'un d'autre trace le chemin ?
Parce que la conviction que ça marche ne vient pas de nulle part. Elle vient de plusieurs années de terrain sur des sujets proches. L'Industry Lab d'Orléans, où nous avons travaillé sur des projets d'automatisation et de robotique légère pour des contextes industriels. SIGRENEA, sur l'IoT industriel — la chaîne capteur → réseau → serveur → décision que nous décrivons dans cet article, nous l'avons déjà assemblée, dans d'autres contextes, avec d'autres contraintes. Ce n'est pas une théorie. C'est une architecture que nous savons faire tenir.
Ce que nous ajoutons ici, c'est la couche aérienne — et c'est là que la nouveauté est réelle. Mais l'essentiel du travail dur, la chaîne d'orchestration LoRaWAN, la logique de décision codée, le service de contrôle MAVLink, nous l'avons des briques fonctionnelles pour chaque maillon. Ce qui manque encore, c'est l'intégration physique sur site et la validation réglementaire. Ce sont des étapes réelles. Elles prendront du temps. Elles n'invalident pas la direction.
Il y a aussi une raison plus concrète. Sur les sites SISKIA que nous ciblons — zones naturelles isolées en France mais aussi, demain, des contextes au Maroc, en Afrique subsaharienne, en Amérique latine — le gap entre l'alerte capteur et la vérification visuelle se mesure parfois en heures de déplacement humain. Dans ces contextes, un drone autonome qui décolle en trente secondes n'est pas un gadget technologique. C'est l'outil qui rend une surveillance sérieuse économiquement possible là où personne ne peut se payer une ronde humaine quotidienne. L'enjeu ne change pas le fait que c'est en conception. Il justifie qu'on le construise.
Ce que l'expérience donne comme conviction
J'ai vu suffisamment de projets IoT industriels se planter non pas sur la technologie mais sur l'architecture de décision — la logique qui transforme un signal en action — pour savoir que c'est là que se joue l'essentiel. Sur le drone SISKIA, cette logique est simple et auditable : deux confirmations → décollage → vol de reconnaissance → transmission → retour → recharge. Pas d'IA opaque dans la boucle, pas de dépendance à un service cloud tiers. Un service Python de 200 lignes, versionné, documenté, que n'importe quelle association technique peut reprendre et modifier. C'est délibéré.
Le chantier ouvert devant nous est précis : finaliser le design mécanique de la station de base, commander les premiers composants pour un prototype physique, engager le dialogue avec la DGAC sur le cadre d'expérimentation, et publier la BOM complète. Nous avons l'intention de tout documenter publiquement — plans, BOM, code source, logs de test. Pas pour faire de la communication. Pour que quelqu'un, quelque part, puisse reprendre exactement là où nous nous arrêtons.
Les autres articles du cluster SISKIA
- SISKIA : du proto au dispositif reproductible à l'internationalLa vue d'ensemble — pourquoi SISKIA, comment ComiPi structure l'association, et ce que "reproductible avec 30 € de composants locaux" veut dire concrètement.
- Le capteur de détection SISKIACe qui déclenche le drone — architecture hardware du capteur, choix des sondes, firmware embarqué, autonomie terrain.
- La gateway LoRaWAN SISKIALe maillon réseau entre le capteur et ChirpStack — hardware retenu, déploiement sur site isolé, fallback 4G.
- siskia.orgLe site de l'association — BOM publiques, schémas ouverts, actualité des déploiements terrain.
- Manifeste — 25 ans à attendre le bon momentPourquoi ComiPi s'implique dans SISKIA, et ce que la réplicabilité internationale signifie pour nous.
Vous travaillez sur un projet similaire ?
Parlons architecture.
Drone autonome, IoT terrain, chaîne capteur-décision sur site isolé. Si vous avancez sur des sujets proches de SISKIA, un échange a probablement de la valeur pour les deux parties.
Suivre l'avancement
Le blog ComiPi
Quand le premier prototype physique sera assemblé, on publiera les plans, la BOM et les premiers logs de vol. Ici, pas ailleurs.