Planifier sur papier avant de construire

Cliquez pour la section précédente : Étape 1

Les décisions d’architecture sont les moins chères à prendre et les plus coûteuses à rater — c’est pourquoi l’Étape 2 se déroule sur papier. Avec des exigences solides en main issues de l’Étape 1, c’est ici que vous créez le plan de haut niveau pour y répondre. Voyez l’architecture système comme la conception d’une ville avant de construire la moindre maison ou route : vous décidez où vont les autoroutes et les ponts avant de couler le béton. Dans un projet IoT, cela signifie esquisser le système global sur papier ou un tableau blanc (le « papier » numérique fonctionne aussi) avant toute soudure ou ligne de code. Cette étape est affaire de vision d’ensemble — prendre maintenant les décisions clés qui façonneront la conception plus tard. À la fin de l’Étape 2, vous aurez un plan clair pour votre produit IoT, et les plans coûtent bien moins cher à modifier que les circuits imprimés.

Visualiser tout le système avec un schéma-bloc

La première étape consiste à dessiner un schéma-bloc de tout le système — un plan d’architecte pour votre appareil IoT et son écosystème. Esquissez tous les composants majeurs et montrez comment ils se connectent et communiquent. Un schéma-bloc IoT simple pourrait ressembler à ceci :

• Capteur → Microcontrôleur (MCU/SoC) → Radio sans fil → Serveur cloud → Application web/mobile (client)

Cette chaîne est le chemin de données de bout en bout. Le capteur collecte les données et les transmet au MCU. Le microcontrôleur peut effectuer un traitement, puis utilise une radio sans fil (Wi-Fi, Bluetooth, LoRa, etc.) pour envoyer les données à un serveur cloud. Le serveur stocke ou analyse les données et les rend disponibles à une interface utilisateur — un tableau de bord web ou une application mobile. Le flux étant tracé, tous les membres de l’équipe peuvent voir toutes les pièces d’un coup d’œil et comprendre comment les données voyagent à travers le système.

Pas d’inquiétude pour les talents de dessinateur — de simples boîtes et flèches suffisent. L’objectif est la clarté. Le schéma-bloc est la carte d’ensemble de votre « ville » IoT : il montre les composants cœur et leurs interactions, et il prévient les malentendus du genre une personne supposant que l’appareil parle directement à une application téléphone alors que vous aviez prévu un passage par une API cloud. Quand tout le monde voit la même carte, moins de gens se perdent plus tard.

Décisions de partitionnement : qui fait quoi (et où) ?

Le système dessiné, l’étape suivante est le partitionnement — décider quelles responsabilités vivent où. Qui fait quoi : quelles tâches reviennent au matériel/appareil, lesquelles au firmware, et lesquelles au cloud ou côté serveur. Ces décisions affectent la performance, le coût, la complexité et la sécurité.

Quelques exemples de décisions de partitionnement dans un système IoT :

• Traitement des données : les données brutes des capteurs doivent-elles être traitées ou filtrées sur l’appareil, ou envoyées brutes au cloud pour un traitement lourd ? Le traitement embarqué réduit la bande passante et la charge cloud, mais exige un MCU plus puissant et peut consommer plus de batterie. Envoyer les données brutes garde l’appareil plus simple, mais le backend doit être robuste et le lien de données a besoin de bande passante suffisante.
• Sécurité des données : allez-vous chiffrer ou compresser les données sur l’appareil avant l’envoi, ou gérer cela dans le cloud ? Chiffrer sur l’appareil protège les données dès qu’elles quittent le capteur, mais en demande plus au MCU. Le faire dans le cloud garde l’appareil plus simple, mais les données voyagent non sécurisées pendant un temps — inacceptable dans les applications sensibles.
• Stockage & intelligence : si la connexion cloud tombe, l’appareil se contente-t-il de bufferiser les données localement — ou prend-il même des décisions locales ? Peut-il fonctionner en mode « dégradé » sans le cloud ? Décider maintenant influence s’il vous faut de la mémoire ou du stockage supplémentaire sur l’appareil, ou une logique supplémentaire pour les scénarios hors ligne.

Le partitionnement est un exercice d’équilibre : chaque partie du système doit traiter ce pour quoi elle est la meilleure. Un petit capteur sur batterie est bon pour collecter des données et faire du traitement léger ; le gros calcul appartient à un serveur cloud qui a de la puissance à revendre. À l’inverse, si l’application exige une réponse très rapide ou doit fonctionner sans internet, plus d’intelligence se déplace vers l’edge. Il n’y a pas de réponse universelle — les arbitrages viennent de vos exigences de l’Étape 1.

Itérer sur ces choix est tout à fait normal. Vous pourriez commencer avec « notre appareil fera tout — pré-traitement, chiffrement, prise de décision » puis réaliser que le MCU choisi ne peut pas gérer la charge, ou que sa mémoire est trop petite. Cet enseignement peut déplacer des tâches vers le cloud. Ou l’inverse : un traitement prévu pour le cloud passe sur l’appareil parce que la latence réseau est un souci. Attraper ces problèmes sur papier coûte bien moins cher que de les découvrir après l’écriture du code ou la fabrication d’un PCB incapable de supporter le firmware. Prenez le temps de bien répartir les responsabilités.

Sélection des technologies : choisir les bons outils pour chaque partie

Avec un schéma-bloc et un partitionnement en place, place à la sélection des technologies : décider des technologies ou composants réels pour chaque bloc — ou au moins réduire les options. Voyez cela comme le choix des matériaux pour chaque partie d’un bâtiment : ossature acier ou bois, murs en brique ou en béton. En termes IoT, les considérations clés incluent :

• Capteurs : de quel(s) capteur(s) avez-vous besoin ? Cela découle des exigences. Des lectures de température de haute précision peuvent appeler un capteur de température numérique avec une interface I²C ; un simple détecteur de seuil peut se contenter d’un capteur analogique et d’un ADC. Considérez la précision, la consommation, le coût et la facilité d’interfaçage avec le MCU.
• Microcontrôleur (MCU) ou System-on-Chip : choisissez le cerveau de l’appareil. Doit-il être ultra-basse consommation (pour fonctionner des années sur une pile bouton) ? A-t-il besoin de puissance de calcul ou de mémoire (pour le traitement embarqué, le machine learning, ou plusieurs capteurs) ? Et l’écosystème — un fournisseur préféré, ou des outils de développement spécifiques ? Vous pourriez réduire à : « Probablement un MCU de la famille ARM Cortex-M4 — CPU correct et virgule flottante pour les calculs de capteurs, avec des modes basse consommation pour le fonctionnement sur batterie. »
• Connectivité (radio sans fil) : sélectionnez comment l’appareil communique, selon la portée, la puissance et les besoins en données. Pour un wearable qui parle à un smartphone, le Bluetooth Low Energy (BLE) convient bien. Pour un gadget domestique avec du Wi-Fi disponible, le Wi-Fi est pratique pour la connectivité cloud. Pour des appareils distants ou à grande échelle, considérez l’IoT cellulaire (LTE-M, NB-IoT) ou les radios longue portée en bande non licenciée comme LoRa ou Sigfox pour les besoins faible débit, longue portée. Chacune a ses arbitrages : Wi-Fi et cellulaire donnent un accès internet mais consomment plus ; BLE est basse consommation mais courte portée ; LoRa est longue portée et basse consommation mais seulement pour de petits paquets.
• Source d’alimentation : comment l’appareil est-il alimenté ? S’il est sur batterie, ce choix façonne tout le reste. Une pile bouton exige des composants ultra-basse consommation partout — MCU, radio, et même le capteur — et des fonctionnalités de gestion d’énergie comme les modes sleep ou un protocole de communication efficace. L’alimentation secteur vous donne la liberté d’utiliser du Wi-Fi gourmand ou un processeur plus fort. Considérez aussi le type de batterie (lithium-ion rechargeable vs remplaçable) et tout circuit de charge.
• Autres composants : selon le système, il peut y avoir d’autres sélections : affichage ou matériel d’UI (LEDs, écrans, boutons), actionneurs (moteurs, relais). Vous n’avez pas encore besoin des références finales pour tout, mais vous devriez avoir une short list de candidats probables pour chaque composant majeur.

Sélectionner les technologies à l’étape d’architecture garde les pièces compatibles entre elles et avec les exigences, et permet des vérifications approximatives de coût et de faisabilité. Si vous avez « probablement » besoin d’un MCU haut de gamme et d’une radio longue portée spécifique, vous pouvez vérifier que le coût combiné rentre dans le budget et que les pièces peuvent fonctionner ensemble (bonnes interfaces ? support de drivers ?). Vous pourriez découvrir qu’un module radio qui vous plaît ne s’apparie qu’avec une certaine famille de MCU ou exige un MCU externe — bon à savoir maintenant.

Gardez aussi la puissance et la taille en tête. Un tout petit appareil sur batterie (un wearable, un capteur distant) peut imposer un system-on-chip intégrant MCU + radio pour économiser l’espace et l’énergie. Un appareil très sensible au coût peut favoriser un module tout-en-un combinant capteur, MCU et radio. C’est l’étape pour jongler avec ces options sur papier et voir quelle stack convient le mieux au projet.

Analyse des risques et des coûts : identifier les pièges potentiels tôt

Même à ce stade, un bon architecte commence à lister les risques et coûts attachés à la conception choisie. Les signaler maintenant vaut mieux que les découvrir plus tard. Choses à considérer :

• Disponibilité des composants & délais : la conception repose-t-elle sur un composant qui pourrait être dur à obtenir ? Il est courant de trouver la puce « parfaite » puis d’apprendre qu’elle a un délai de 30 semaines ou qu’elle est perpétuellement en rupture. Un capteur de pointe peut remplir toutes les specs mais être si nouveau que l’offre est limitée. Identifiez ces pièces tôt et préparez des solutions de rechange ou des plans d’approvisionnement. Même chose pour les composants à source unique — un fournisseur, un point de défaillance.
• Facteurs de coût : parcourez le schéma-bloc et la BOM approximative à la recherche d’éléments coûteux. Un MCU haut de gamme ou un module cellulaire peut dominer le coût ; le business case le permet-il ? Sinon, reconsidérez maintenant. Le volume compte aussi : 2 $ de plus par appareil, c’est anodin pour 10 prototypes mais significatif à 100 000 unités. Ajustez l’architecture si nécessaire — peut-être que le MCU avec 1 Mo de flash n’est pas nécessaire si 256 Ko plus un peu plus de traitement cloud suffisent.
• Points de défaillance uniques : pensez à la fiabilité. Tout le système casse-t-il si un composant tombe en panne ou passe hors ligne ? Si l’appareil perd la connectivité cloud, devient-il inutile ? Si oui, ajoutez une sauvegarde locale — ne serait-ce que stocker les données pour les envoyer plus tard, ou un mode « hors ligne » basique. Si le système repose sur un seul serveur cloud, considérez la redondance ou au moins un plan de downtime. Repérer les points faibles maintenant vous permet de concevoir des mesures d’atténuation : une petite batterie de secours pour l’horloge temps réel, de la mémoire pour loguer les données quand l’alimentation ou le réseau tombe.
• Problèmes réglementaires et de conformité : un risque d’architecture souvent négligé. Une technologie sans fil donnée peut exiger une certification FCC/CE pour les émissions radio ; certaines bandes de fréquences ont des restrictions légales dans certains pays. Un usage médical ou industriel apporte ses propres normes (réglementations des dispositifs médicaux, indices de sécurité). Soulignez les besoins de conformité connus maintenant pour budgéter temps et argent. Un module cellulaire peut exiger des certifications d’opérateur, qui prennent du temps ; LoRa dans une région donnée signifie respecter les limites de duty-cycle et de puissance. Repérer ces points tôt évite le « on ne peut pas livrer parce qu’on n’a jamais été certifiés » de dernière minute.
• Risques d’intégration et de complexité : signalez tout ce qui est techniquement risqué — une plateforme IoT très nouvelle, une bibliothèque firmware expérimentale. Reconnaissez-le comme un risque : planifiez un prototype rapide ou un spike de recherche pour le tester, et gardez une solution de repli. Une conscience précoce de « ce qui pourrait mal tourner » vous permet de le concevoir hors du chemin ou de préparer un plan B.

Une analyse des risques et des coûts à l’Étape 2 signifie entrer dans le développement les yeux ouverts. Si la partie la plus risquée est un algorithme de machine learning personnalisé sur l’appareil, attaquez-la en premier ou surveillez-la de près. Si le composant le plus cher est un certain capteur, soyez prudent avec le budget ailleurs. Aucun produit n’est sans risque, mais la planification proactive est ce qui sépare les projets calmes des courses affolées de dernière minute.

Documenter l’architecture clairement

À la fin de l’étape d’architecture, documentez l’architecture système pour qu’elle soit compréhensible et partageable par toute l’équipe. Ce document devient le plan auquel tout le monde se réfère, il doit donc vivre quelque part d’accessible — pas enfermé dans la tête de l’ingénieur principal.

Façons clés de capturer et communiquer l’architecture :

• Diagrammes visuels : montrez le système sous différentes perspectives. Un schéma-bloc simple (comme ci-dessus) couvre le contexte de haut niveau du matériel et des principales pièces logicielles. Certaines équipes utilisent des notations formelles comme SysML ou le modèle C4 — optionnel, mais utile. L’enjeu est d’illustrer comment matériel, firmware, services cloud et utilisateurs interagissent. Pour le logiciel (firmware de l’appareil et cloud), un diagramme de composants UML — ou même un croquis annoté — peut montrer quels modules tournent sur l’appareil versus le serveur. Ne vous laissez pas rebuter par les acronymes : des boîtes et flèches étiquetées dans n’importe quel outil communiquent bien. Utilisez le style que votre équipe lit le mieux.
• Vue d’ensemble écrite : accompagnez les diagrammes d’un bref texte décrivant chaque bloc et son rôle : « MCU : responsable de lire le capteur et de chiffrer les données » ; « Cloud : responsable du stockage des données, de l’analytique, et de fournir la REST API pour l’application. » Quelques paragraphes ou puces sous le diagramme lèvent l’ambiguïté.
• Bill of Materials (BOM) préliminaire : démarrez une feuille de calcul BOM basique listant les composants clés (capteur, MCU, module radio) avec des notes sur le coût estimé, le fournisseur, et le délai ou la disponibilité. Pas chaque résistance et condensateur — ceux-là viennent en conception détaillée — juste les pièces majeures, pour que le coût unitaire et les risques de chaîne d’approvisionnement soient visibles. Si la BOM montre le module sans fil à 10 $ et tout le reste à 2 $ combinés, vous voyez immédiatement où l’optimisation de coût compte. Si deux pièces majeures viennent du même fournisseur, notez-le aussi — pratique, ou un risque.
• Notation & cohérence : avec plusieurs contributeurs, accordez-vous sur le nommage. Si le diagramme dit « Device CPU », les autres documents ne devraient pas alterner au hasard entre « microcontrôleur » et « CPU » — l’incohérence embrouille. Gardez les étiquettes cohérentes et la documentation versionnée (un document partagé ou une page wiki suffit). Beaucoup d’équipes rassemblent les diagrammes et notes dans un court document d’architecture qui circule pour feedback et sert de référence pendant le développement.

L’objectif : tout membre de l’équipe — y compris un nouvel arrivant — peut regarder l’architecture et se mettre à niveau rapidement. Cela aide aussi avec les parties prenantes non-ingénieures : les chefs de produit ou les dirigeants ne liront peut-être pas votre code, mais ils peuvent lire un diagramme de haut niveau. Une bonne documentation d’architecture comble le fossé entre les idées et l’implémentation.

« Concevoir deux fois, construire une fois » : gagner du temps avec la planification précoce

Il y a un mantra en ingénierie : « concevoir deux fois, construire une fois ». Attraper et corriger les problèmes d’une conception sur papier coûte bien moins cher que de les corriger dans un produit construit — c’est toute la philosophie de l’Étape 2. Déplacer des boîtes et des flèches dans un diagramme fait beaucoup moins mal que re-spinner un PCB ou réécrire un module firmware parce que le plan d’origine s’est révélé défectueux.

Utilisez cette étape pour mettre toute l’équipe sur la même longueur d’onde tôt. L’architecture est multidisciplinaire : ingénieurs matériel, développeurs firmware, ingénieurs cloud/backend, chefs de produit. Chacun devrait avoir voix au chapitre dans la revue, alors encouragez la discussion. Un ingénieur cloud pourrait dire : « Si l’appareil horodatait chaque lecture avant l’envoi, mon côté serveur serait plus simple » — une petite demande, si vous la connaissez en amont. Un concepteur matériel pourrait noter : « Nous utilisons deux capteurs maintenant, mais un troisième nous permettrait de mesurer la qualité de l’air — devrait-on laisser de la place ? » Des enseignements comme ceux-là mènent à de petits ajustements d’architecture, ou au moins à des dispositions pour une expansion future, qui ne remontent jamais quand les équipes travaillent en isolation. Aplanir les points d’interface maintenant vaut mieux que le moment « on ne peut plus changer ça » plus tard.

La minutie ici construit la confiance. À la fin de l’Étape 2, vous devriez avoir un plan clair : une conception de haut niveau montrant comment vous comptez répondre aux exigences de l’Étape 1. Comme le dessin d’architecte d’un bâtiment, il ne choisit pas encore les couleurs de peinture ni les poignées de porte — mais les étages, les portes, les fenêtres et le plan des pièces sont arrêtés. En termes IoT : vous savez ce que sont les appareils, comment ils se connectent, quelles données vont où, et à peu près quelle technologie fait le travail.

Avec ce plan en main, vous pouvez passer à la conception détaillée et à l’implémentation en confiance. Vous avez créé une carte pour le voyage IoT, donc vous avez beaucoup moins de chances de vous perdre. À l’Étape 3 et au-delà — construire le matériel, écrire le code — vous vous référerez constamment à cette architecture. Et quand les changements arriveront (ils arrivent toujours), mettez à jour le document d’architecture pour qu’il reste une référence fiable.

En bref : l’Étape 2, Architecture système, est l’endroit où vous mettez le projet sur la voie du succès. Elle aligne l’équipe, expose les risques tôt, et fournit un plan clair. Vous l’avez conçu — peut-être deux fois — donc maintenant vous pouvez le construire une fois, et le construire correctement. Gardez le plan à portée de main ; il sera votre étoile du berger pour le reste du voyage.