Bureau d'études IoT : conception d'objets connectés et de capteurs sans fil

Un projet IoT n'est pas un projet électronique avec une radio en plus. C'est un système complet qui doit fonctionner sur le terrain pendant des années, avec une autonomie énergétique souvent contrainte, dans des environnements parfois hostiles, avec des exigences de sécurité élevées, le tout pour un coût unitaire compatible avec un déploiement à grande échelle. Cette combinaison de contraintes oblige à des arbitrages spécifiques que tous les bureaux d'études n'ont pas l'habitude de traiter.

Cette page présente notre approche des projets IoT, de la conception de l'objet connecté à son déploiement, en complément de notre offre de bureau d'études électronique et de conception produit électronique.

Ce qui rend un projet IoT spécifique

Trois caractéristiques distinguent un projet IoT d'un projet électronique classique.

D'abord, la connectivité longue distance ou très basse consommation. Un produit IoT communique sans fil, souvent vers une infrastructure (gateway, cloud, application mobile), sur des distances qui vont du mètre au kilomètre, avec des budgets énergétiques qui vont de la batterie permanente au capteur sur pile pour 10 ans. Choisir la bonne technologie radio et bien la mettre en œuvre conditionne la viabilité du produit.

Ensuite, l'autonomie énergétique est presque toujours un facteur dimensionnant. Un capteur qui doit fonctionner cinq ans sur une pile CR2032 ne se conçoit pas comme un produit alimenté en permanence. Chaque microampère compte, et la consommation se gère à tous les niveaux : composants, architecture, firmware, protocole radio.

Enfin, le déploiement à l'échelle transforme des problèmes mineurs en problèmes critiques. Un défaut qui touche 1 % des produits n'a pas le même impact si vous en déployez 100 ou 100 000. La rigueur de conception, les tests de production et la stratégie de mise à jour à distance prennent une importance proportionnelle au nombre d'unités prévues.

Le stack IoT complet : du capteur au cloud

Un système IoT complet mobilise typiquement cinq couches techniques, qui doivent être pensées ensemble.

L'objet connecté (capteur, actionneur, produit final) est l'élément physique : carte électronique, alimentation, antenne, mécanique, capteurs ou actionneurs spécifiques. C'est notre cœur de métier.

La connectivité est la liaison entre l'objet et l'infrastructure : LoRaWAN, NB-IoT, LTE-M, Sigfox, BLE, Wi-Fi, Zigbee, Thread, ou des liaisons filaires (Modbus, CAN, Ethernet). Chaque technologie a ses caractéristiques propres en portée, débit, consommation, coût d'infrastructure.

La gateway ou passerelle (si pertinente) agrège les communications des objets et les relaie vers le cloud. Sur certaines architectures (LoRaWAN, Zigbee), la gateway est indispensable. Sur d'autres (NB-IoT direct, cellulaire), elle peut être absente.

Le backend cloud reçoit les données, les stocke, les traite, les expose aux utilisateurs. Nous concevons l'interface entre l'objet et le cloud (protocoles, formats de données, gestion des erreurs), mais coordonnons avec des partenaires ou avec l'équipe IT du client pour le développement backend lui-même.

L'interface utilisateur (application mobile, web app, dashboard) permet aux utilisateurs finaux d'interagir avec le système. Idem, conception coordonnée avec partenaires spécialisés.

Notre intervention couvre intégralement les couches 1 à 3 (objet, connectivité, gateway), et joue le rôle d'interface technique avec les couches 4 et 5 (cloud, UI).

Choisir la technologie radio : un arbitrage structurant

Le choix de la technologie radio est l'une des décisions les plus structurantes d'un projet IoT. Une fois fait, il est très coûteux à remettre en cause. Voici comment nous l'abordons.

LoRaWAN

Le LoRaWAN (868 MHz en Europe) offre une portée exceptionnelle (plusieurs kilomètres en environnement dégagé, plusieurs centaines de mètres en urbain dense) et une consommation très faible. Il convient parfaitement aux capteurs déployés sur de grandes zones avec peu de données à transmettre (quelques messages par jour de quelques dizaines d'octets).

Il nécessite une infrastructure de réseau, soit publique (opérateurs comme Objenious, Bouygues Telecom, Orange), soit privée (gateways déployées par le client). Le LoRaWAN public est pratique pour des déploiements légers ; le LoRaWAN privé devient pertinent à partir de quelques centaines d'objets sur un site dédié (industrie, agriculture, smart building).

NB-IoT et LTE-M

Le NB-IoT et le LTE-M sont des technologies cellulaires bas débit, opérées par les opérateurs télécom traditionnels. Elles offrent une couverture nationale, une bonne portée et une consommation correcte. Le NB-IoT est plus économe et plus adapté aux faibles volumes de données ; le LTE-M permet une mobilité (handover) et des débits supérieurs.

Avantage majeur : pas d'infrastructure à déployer. Inconvénient : un coût opérationnel récurrent (abonnement par objet) qu'il faut intégrer au modèle économique du produit. La couverture, désormais bonne en zone urbaine et péri-urbaine, peut être insuffisante en zone rurale ou en intérieur de bâtiment.

Sigfox

Sigfox est l'autre standard bas débit longue portée. Il a perdu en attractivité ces dernières années (incertitudes commerciales, perte d'opérateurs locaux dans certains pays) et nous ne le recommandons généralement plus pour de nouveaux projets, sauf cas particulier.

BLE (Bluetooth Low Energy)

Le BLE convient aux usages courte portée (quelques dizaines de mètres) avec un appairage à un smartphone ou une gateway locale. C'est la solution standard pour les objets grand public (wearables, accessoires connectés, objets domestiques), les balises (beacons), et les capteurs industriels appairés à un terminal mobile.

Sa consommation est très faible, son écosystème mature, son coût de mise en œuvre minimal. En revanche, il n'offre pas de connexion autonome au cloud : il faut une infrastructure relais.

Wi-Fi et Zigbee/Thread

Le Wi-Fi est l'option pour les objets connectés en environnement domestique ou tertiaire avec infrastructure disponible. Sa consommation reste plus élevée que les protocoles bas débit, ce qui le limite aux objets alimentés ou à batterie rechargeable régulièrement.

Zigbee et Thread sont des protocoles maillés courte portée, utilisés dans le smart home et le smart building. Ils nécessitent une gateway et une infrastructure (mais permettent un maillage qui étend la portée de proche en proche).

Cellulaire 4G/5G

Pour les produits demandant du débit (vidéo, données volumineuses) ou de la mobilité (véhicules, équipements transportés), le cellulaire 4G ou 5G reste la solution. Consommation plus élevée, coût d'abonnement plus important, mais capacités hors de portée des protocoles bas débit.

Le choix se fait sur quatre critères

En pratique, le choix se fait en croisant : la portée et la couverture nécessaires, la consommation acceptable selon l'alimentation prévue, le modèle économique (abonnement vs infrastructure à déployer), le volume de données à transmettre. Aucune technologie n'est universellement meilleure : c'est le profil du projet qui détermine le bon choix.

Autonomie énergétique : un travail de fond

L'autonomie d'un objet sur pile ou sur batterie est l'un des sujets les plus délicats du métier IoT. Quelques principes que nous appliquons systématiquement.

Budgétiser l'énergie dès la conception. Nous établissons un budget énergétique théorique avant le moindre développement : combien de microampères en veille, combien en transmission, combien de transmissions par jour, quelle capacité de pile pour quelle durée. Ce budget structure tous les choix techniques suivants.

Choisir les composants en mode veille profonde. La différence entre un microcontrôleur en sleep à 1 µA et le même à 10 µA semble minime. Sur 10 ans avec une CR2032, c'est la différence entre un produit qui tient son autonomie et un produit qui ne la tient pas. Cette discipline s'étend à tous les composants : capteurs, radios, supervisons, références de tension.

Optimiser le firmware pour le sleep. Un firmware mal conçu peut maintenir des périphériques actifs alors qu'ils pourraient être en veille, ou refuser le passage en sleep profond à cause d'une horloge mal gérée. Quelques jours d'optimisation firmware peuvent doubler l'autonomie d'un produit.

Mesurer, mesurer, mesurer. Nous mesurons systématiquement la consommation réelle des prototypes, avec des outils précis (analyseurs de courant haute dynamique). Les écarts entre prévision théorique et mesure réelle sont fréquents et leur analyse permet d'identifier les fuites de consommation.

Vieillir les batteries. La capacité d'une pile dépend de sa température, de son âge, de son profil de décharge. Un calcul d'autonomie basé sur la capacité nominale d'une pile neuve à 25 °C surestime la durée réelle. Nous appliquons des marges et nous testons en conditions représentatives.

Sécurité : le sujet qui ne peut plus être ignoré

La sécurité des objets connectés est passée d'un sujet optionnel à une exigence centrale. Les attaques sur des flottes IoT sont documentées, les régulations se durcissent (Cyber Resilience Act au niveau européen, exigences sectorielles), et les utilisateurs sont de plus en plus attentifs.

Une démarche sécurité minimale couvre plusieurs niveaux.

Le chiffrement des communications entre l'objet et le cloud est aujourd'hui la base. Selon les protocoles utilisés, il peut être natif (LoRaWAN, BLE secure, MQTT over TLS) ou à mettre en place explicitement.

L'authentification mutuelle entre l'objet et le serveur empêche les attaques d'usurpation. Elle s'appuie typiquement sur des certificats ou des clés stockées dans des éléments sécurisés (Secure Element) intégrés à la carte.

Le stockage sécurisé des clés dans l'objet évite qu'un attaquant ayant accès physique à un objet puisse extraire les secrets et compromettre l'ensemble de la flotte.

Le secure boot garantit que seul un firmware signé par le fabricant peut s'exécuter sur l'objet, empêchant l'installation de firmwares malveillants.

La mise à jour à distance (FOTA / OTA) est indispensable pour corriger les vulnérabilités découvertes après déploiement. Elle doit elle-même être sécurisée (signature, intégrité, rollback en cas d'échec).

Toutes les applications ne nécessitent pas l'ensemble de ces mesures. Mais elles doivent être discutées explicitement en début de projet, pas après que les premiers objets soient déployés.

Certifications spécifiques aux produits IoT

Un objet connecté commercialisé en Europe doit obtenir le marquage CE, qui couvre plusieurs directives selon le produit.

La directive RED (Radio Equipment Directive 2014/53/UE) s'applique à tout produit émettant des ondes radio. Elle impose des tests spécifiques sur la performance radio, la CEM, la sécurité électrique. Les tests RED sont conduits en laboratoires accrédités et représentent typiquement 10 à 30 k€ selon la complexité du produit.

La directive CEM (2014/30/UE) couvre la compatibilité électromagnétique, en émissions et en immunité. Elle s'applique à tous les produits électroniques, y compris non radio.

Selon les usages, d'autres directives peuvent s'appliquer : directive basse tension pour les produits avec alimentation secteur, directive RoHS pour la restriction des substances dangereuses, certifications sectorielles (médical, automobile, ferroviaire) avec leurs exigences propres.

Une conception bien menée passe ces certifications du premier coup, ce qui n'est pas la même chose que d'espérer les passer. Nous concevons en respectant les règles applicables dès la phase architecture (CEM, antennes, isolation), et nous validons par des pré-tests en chambre semi-anéchoïque sur les prototypes avant le passage en laboratoire externe.

Du proto au déploiement : monter en cadence

Le passage du prototype au déploiement à grande échelle est l'une des phases les plus délicates d'un projet IoT. Plusieurs points méritent une attention spécifique.

La production série doit garantir une qualité reproductible. Les tests fonctionnels en production (notamment des tests radio) sont indispensables pour éviter qu'un produit défaillant arrive chez l'utilisateur. Notre activité de fabrication électronique intègre nativement ces tests.

La provisioning (configuration initiale de chaque objet : clés, certificats, identifiants réseau) doit être automatisée pour permettre le déploiement à grande échelle. Configurer manuellement 10 objets est trivial ; configurer 10 000 objets manuellement est impossible.

La logistique spécifique aux objets IoT (date d'activation, gestion des piles, conditions de stockage) doit être anticipée. Un objet sur pile activé en stock pendant un an perd un an d'autonomie.

Le support et la maintenance des produits déployés mobilisent des outils spécifiques : monitoring de la flotte, mise à jour FOTA, gestion des incidents, retours pour analyse. Ces outils doivent être prévus en amont, pas après les premiers déploiements.

FAQ — Bureau d'études IoT

Faites-vous aussi le développement du backend cloud et de l'application mobile ? Nous concevons l'interface technique entre l'objet et le cloud (protocoles, formats, sécurité), mais le développement backend cloud et application mobile est réalisé par des partenaires spécialisés avec lesquels nous coordonnons. Cette répartition garantit l'expertise sur chaque couche du stack.

Pouvez-vous accompagner sur le choix de l'opérateur LoRaWAN ou cellulaire ? Oui. Nous restons neutres entre opérateurs et nous évaluons les options selon votre cas : couverture sur votre zone, modèles tarifaires, qualité de service, intégration aux plateformes existantes. Cette évaluation fait partie du cadrage initial sur les projets concernés.

Quel est le coût de développement typique d'un objet connecté ? Pour un capteur connecté simple sur protocole bas débit : 50 à 120 k€ de développement complet, hors mécanique sur mesure. Pour un objet plus riche (multi-capteurs, IHM, batterie rechargeable) : 120 à 300 k€. Pour un produit complexe ou réglementé : 300 k€ et au-delà.

Quelle autonomie peut-on atteindre en pratique sur un capteur ? Pour un capteur LoRaWAN qui transmet quelques fois par jour, 5 à 10 ans sur deux piles AA ou une grosse capacité lithium sont atteignables, à condition de tout faire bien. Pour un capteur BLE actif quelques heures par jour, plusieurs mois à un an sur CR2032. Pour un capteur en transmission permanente, on bascule sur batterie rechargeable ou alimentation secteur.

Pouvez-vous reprendre un projet IoT déjà entamé ? Oui, c'est fréquent. Nous démarrons par un audit du projet existant : architecture, choix techniques, qualité du code firmware, niveau de validation. L'audit débouche sur un plan d'action chiffré pour reprendre ou compléter le projet.

Travaillez-vous sur des projets industriels ou seulement grand public ? Les deux. Notre clientèle est majoritairement B2B (industriel, agritech, smart building, médical), avec quelques projets grand public via des startups. Les contraintes diffèrent (durée de vie, fiabilité, volumes) mais la méthodologie reste structurellement la même.

Comment gérez-vous l'évolutivité long terme des produits IoT ? Trois leviers structurels : architecture firmware modulaire permettant des évolutions, OTA dès la conception pour mettre à jour la flotte, choix de composants à roadmap long terme (statut actif, second source). Ces choix se font en début de projet et déterminent la capacité à faire vivre le produit.

Discutons de votre projet IoT

Pour un premier échange, transmettez-nous une description de votre projet : nature de l'objet, fonctions cibles, environnement de déploiement, volumes prévisionnels, contraintes d'autonomie. Un rendez-vous de cadrage permet d'évaluer la faisabilité et de dimensionner les étapes. Pour les clients en région nantaise, voir notre page bureau d'études à Nantes.