Les priorités d’abord !

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

Les exigences viennent en premier dans tout projet IoT bien mené — avant les schémas, avant le firmware, avant la première ligne de code. Vous avez décidé que votre idée de produit mérite d’être gardée, et la tentation maintenant est de sauter directement dans la construction. Résistez. L’Étape 1 consiste à rassembler les exigences, la fondation de tout ce qui suit. Cela semble peut-être moins excitant que de mettre sous tension un nouveau circuit ou d’écrire du code, mais voyez cela comme le tracé de la carte avant de prendre la mer. Les voyages sans carte sont aventureux, certes — ils finissent juste rarement bien.

Dans l’Étape 1 : Exigences des parties prenantes & du système, nous recueillons les entrées de tous les acteurs clés et définissons exactement ce que nous construisons et pourquoi : ce que le produit doit faire, les conditions qu’il doit remplir, et les contraintes qu’il doit respecter. Le temps investi ici se rembourse plus tard. Chaque décision de conception, chaque ligne de code et chaque test en aval remontera à ces exigences — elles sont l’étoile du berger du projet. Foncez sans elles et vous risquez de construire la mauvaise chose, ou de découvrir après des mois de travail qu’une fonctionnalité clé a été oubliée ou qu’une hypothèse était fausse.

Dans ce chapitre, nous décomposons ce que signifie capturer les exigences des parties prenantes et du système : pourquoi cette étape compte, les types d’exigences à considérer, et comment les documenter clairement. Nous partagerons aussi des exemples montrant comment verrouiller les exigences tôt peut faire ou défaire un projet IoT.

Que sont exactement les exigences ?

Alors, que voulons-nous dire par « exigences » ? En termes simples, c’est une description détaillée de ce que votre produit doit faire et dans quelles conditions il doit le faire — le règlement du projet, capturant tout ce qui est attendu de l’appareil avant de le construire. Si votre produit était une histoire, les exigences seraient le plan de l’intrigue : elles garantissent que tous les éléments clés sont définis pour que l’histoire se tienne à la fin.

Les exigences se déclinent en quelques saveurs, chacune couvrant un aspect différent du produit :

• Exigences fonctionnelles : ce que le produit doit faire — ses fonctionnalités et comportements.
• Exigences non fonctionnelles : les qualités et contraintes du produit — ses performances, sa durée de vie, etc.
• Exigences d’interface : comment le produit va interagir avec d’autres systèmes et le monde extérieur.

Nous passerons chaque catégorie en détail. Pour l’instant, retenez qu’une bonne exigence est claire, spécifique et testable. « L’appareil devrait être génial » n’aidera pas votre équipe d’ingénierie. « L’appareil doit mesurer la température de 0 °C à 50 °C avec une précision de ±0,5 °C », si : quiconque le lit sait exactement ce qui est attendu, et plus tard vous pourrez tester si l’appareil y répond. C’est le niveau de clarté à viser.

Exigences fonctionnelles

Les exigences fonctionnelles décrivent les fonctionnalités, fonctions et comportements spécifiques de votre produit IoT — ce que le système doit faire. Si quelqu’un demande « Que fait votre appareil ? », la réponse est un résumé de ses exigences fonctionnelles : les actions et services que l’appareil fournit à l’utilisateur ou à d’autres systèmes.

Pour un appareil IoT, les exigences fonctionnelles incluent souvent :

• Détection de données ou actions : quelles données l’appareil mesure-t-il, ou quelles actions effectue-t-il ? (p. ex. mesure la température, ouvre une vanne, suit une position)
• Précision et plage des données : quelle est la précision des mesures, et sur quelle plage ? (p. ex. mesure la température de 0 °C à 50 °C avec une précision de ±0,5 °C)
• Fréquence ou timing : à quelle fréquence remplit-il sa fonction — mises à jour chaque minute, chaque heure ? Avec quelle rapidité doit-il répondre ? (p. ex. une lecture toutes les 10 minutes, ou une réponse en moins de 2 secondes)
• Traitement des données : qu’advient-il des données — envoyées au cloud, loguées sur une carte mémoire, affichées sur un écran ?
• Modes ou fonctionnalités spécifiques : par exemple, un mode alarme quand un seuil est franchi, l’auto-calibration, ou les mises à jour firmware over-the-air.

Un exemple concret. Supposons que vous construisiez un simple capteur de température IoT pour la maison connectée. Quelques exigences fonctionnelles pourraient être :

• L’appareil doit mesurer la température ambiante de 0 °C à 50 °C avec une précision de ±0,5 °C.
• L’appareil doit prendre une lecture de capteur au moins une fois toutes les 10 minutes (taux de rafraîchissement).
• Après chaque lecture, l’appareil doit transmettre les données du capteur à un serveur cloud en moins de 30 secondes (latence des données).
• L’appareil doit faire clignoter une LED et envoyer une alerte si la température dépasse un seuil défini par l’utilisateur.

Chacune décrit quelque chose que le système fait, généralement formulée « L’appareil doit… » suivi d’un comportement spécifique. Ce format rend la vérification directe plus tard : soit l’appareil fait X comme spécifié, soit il ne le fait pas.

De bonnes exigences fonctionnelles dessinent une image claire des capacités, pour que l’équipe d’ingénierie sache exactement quoi implémenter. Seulement ensuite les concepteurs matériel et logiciel peuvent réfléchir au comment — le quoi vient en premier, c’est pourquoi ces exigences sont définies maintenant. Sans elles, vous pouvez vous retrouver avec un produit qui manque ce dont l’utilisateur a réellement besoin : une station météo IoT élaborée, disons, livrée sans capteur d’humidité parce que personne ne l’a écrit. Définir les exigences fonctionnelles en amont capture les fonctionnalités indispensables avant que cela n’arrive.

Exigences non fonctionnelles

Les exigences non fonctionnelles spécifient les qualités, conditions et contraintes du produit plutôt que ses fonctionnalités : à quel point il performe, sa robustesse, et quelles limites il doit respecter. Elles posent les garde-fous de la qualité globale, et elles sont aussi critiques que les fonctionnalités elles-mêmes — elles gardent l’appareil sûr, fiable et pratique dans le monde réel.

Considérations non fonctionnelles courantes pour un appareil IoT :

• Consommation & autonomie de batterie : combien de temps l’appareil doit-il fonctionner sur une source d’alimentation donnée ? Par exemple, « Le produit doit fonctionner sur une seule pile AA pendant au moins 1 an. » Cela force l’attention sur des composants basse consommation et une gestion d’énergie efficace.
• Fiabilité & longévité : quelle robustesse l’appareil doit-il avoir dans le temps ? Souvent exprimée en Mean Time Between Failures (MTBF) ou similaire — « L’appareil devrait fonctionner en continu pendant au moins 5 ans sans défaillance critique. » Cela influence la sélection des composants et les marges de conception.
• Sécurité & confidentialité : comment protégerez-vous les données et la vie privée des utilisateurs ? P. ex. « Toutes les transmissions de données doivent être chiffrées en AES-256 » ou « Les identifiants utilisateur doivent être stockés de façon sécurisée et jamais transmis en clair. » Dans le paysage IoT actuel, les exigences de sécurité sont essentielles pour prévenir les brèches.
• Contraintes environnementales & physiques : les conditions que l’appareil doit supporter, plus les limites de taille et de poids. « L’appareil doit fonctionner de −20 °C à +60 °C et résister à l’eau selon IP67 » garantit qu’il survit aux environnements rudes ; « L’appareil ne doit pas peser plus de 100 grammes et doit tenir dans un espace de 10 cm x 5 cm x 3 cm » le maintient dans le facteur de forme requis.
• Contraintes de coût : vous avez probablement un coût cible — « Le coût de fabrication unitaire ne doit pas dépasser 50 $. » Cela pilote les arbitrages : un composant moins cher ici, une fonctionnalité abandonnée là.
• Conformité réglementaire : beaucoup de produits IoT doivent répondre à des normes ou certifications — « L’appareil doit être conforme aux réglementations CE et FCC pour la communication sans fil », ou « Doit respecter la norme de sécurité ISO 13849 » s’il fait partie d’un système de machine. Ce sont des exigences non négociables posées par les normes sectorielles et de sécurité.

C’est une longue liste, mais voyez les exigences non fonctionnelles comme les attributs de qualité que le produit doit avoir. Elles font rarement la brochure marketing, pourtant les ignorer fait échouer le produit de façons moins visibles. Un capteur peut rapporter des données parfaitement (fonctionnel !) et quand même frustrer chaque utilisateur parce que sa batterie meurt en un jour. Un appareil peut bien performer au labo et quand même tomber à la première attaque parce que la sécurité n’a pas été intégrée dès le départ.

Définir ces qualités en amont garantit que le produit final n’est pas seulement riche en fonctionnalités, mais robuste, utilisable et viable. Les exigences non fonctionnelles guident les choix de composants, l’architecture logicielle (fiabilité, sécurité), la conception mécanique (durabilité, taille), et même la façon dont vous testerez. Elles travaillent en coulisses, mais elles sont essentielles pour répondre aux attentes des parties prenantes et survivre au déploiement réel.

Exigences d’interface

Les exigences d’interface définissent comment votre produit se connecte et interagit avec le monde extérieur — physiquement et logiquement. Les interfaces sont les points de contact entre votre appareil et tout le reste : autre matériel, sources d’alimentation, boîtiers, utilisateurs et systèmes logiciels. Cette catégorie garantit que l’appareil s’intègre dans son écosystème prévu, et y communique correctement.

Aspects couverts par les exigences d’interface :

• Interfaces électriques : toute connexion ou signal électrique. L’appareil a-t-il besoin d’une entrée d’alimentation spécifique (USB-C, bornes de batterie) ? Émet-il une tension analogique (un signal 0-5 V) ou fournit-il une interface numérique (I²C, SPI, UART) à d’autre matériel ? Une exigence pourrait être « L’appareil doit avoir un port USB-C pour l’alimentation et la connectivité données » ou « Il doit fournir une sortie analogique 0-5 V proportionnelle à la lecture du capteur. »
• Interfaces de communication : comment l’appareil parle au cloud, à un smartphone ou à d’autres appareils — réseau et protocoles. Par exemple, « L’appareil doit se connecter au cloud via Wi-Fi et utiliser le protocole MQTT pour publier les données des capteurs », ou « Il doit supporter le Bluetooth Low Energy (BLE) pour communiquer avec une application smartphone. » Si une API est nécessaire, spécifiez-la aussi : « Le service cloud doit fournir un endpoint REST API pour récupérer les données de l’appareil. »
• Interfaces mécaniques : la forme et l’ajustement physiques. Quelle taille maximale pour l’appareil, et comment est-il monté ou enfermé ? « Le PCB de l’appareil doit faire 5 cm x 5 cm pour rentrer dans un boîtier standard », ou « Il doit avoir des trous de fixation compatibles avec un support de style GoPro. » L’étanchéité à l’eau et à la poussière est à la fois une exigence environnementale et une considération d’interface mécanique : « Le boîtier doit être certifié IP67 pour la résistance à l’eau et à la poussière. » L’enjeu est que l’appareil s’intègre physiquement là où il est censé aller.
• Interface utilisateur (UI) & contrôles : les éléments avec lesquels l’utilisateur interagit — boutons, écrans, LEDs. « L’appareil doit inclure un bouton de reset physique accessible à l’utilisateur », ou « Il doit avoir une LED indicatrice qui clignote pendant la transmission de données. » Celles-ci définissent comment les utilisateurs obtiennent des informations de l’appareil ou lui envoient des commandes.

Verrouiller les exigences d’interface clarifie comment toutes les pièces s’assemblent. Si vous concevez un capteur qui se fixe sur une machine industrielle, une exigence d’interface mécanique spécifie la taille et le motif des trous de vis pour qu’il rentre vraiment. Si l’appareil est sur batterie, une exigence d’interface électrique garantit un connecteur standard pour que l’utilisateur puisse le recharger facilement. En manquer une, et vous obtenez le résultat classique : un appareil parfaitement bon auquel personne ne peut se connecter parce qu’il lui manque le bon port.

En bref, les exigences d’interface garantissent que votre appareil fonctionne avec son environnement et ses utilisateurs — qu’il s’agisse d’une maison connectée, d’une installation industrielle ou d’une personne avec un téléphone. Les négliger fait souvent la différence entre un produit compatible et convivial et un produit qui cause des maux de tête à l’intégration.

Impliquer les parties prenantes tôt

D’où viennent toutes ces exigences ? Pas de nulle part — vous les recueillez auprès de vos parties prenantes : tous ceux qui ont un intérêt dans le succès du produit. Cela inclut les candidats évidents, utilisateurs finaux et clients, mais aussi le marketing, les ventes, des ingénieurs de différentes disciplines (matériel, logiciel, firmware), des chefs de projet, et des experts réglementaires ou de conformité. Chaque groupe a ses propres besoins et préoccupations, et les exigences devraient capturer chaque perspective critique.

Identifiez vos parties prenantes et impliquez-les tôt, car elles définissent à quoi ressemble le « succès ». Le marketing peut dire : « Il faut que ça coûte moins de 50 $ et que ça tienne un an sur une charge — c’est ce que nos clients attendent. » Les utilisateurs finaux (ou une persona représentative) peuvent avoir besoin d’une configuration simple et d’une maintenance minimale. L’équipe logicielle peut avoir besoin d’une API robuste pour s’intégrer à une plateforme cloud. L’expert sécurité insistera sur le chiffrement et l’authentification. Un responsable conformité vous rappellera les limites d’émission radio FCC ou les normes de sécurité électrique. Toutes ces entrées deviennent des exigences.

Faire remonter ces besoins maintenant coûte bien moins cher que plus tard. Des sessions de brainstorming, des ateliers ou de simples entretiens avec chaque groupe de parties prenantes construiront une liste complète. Ne le faites pas en vase clos : une exigence écrite sans l’apport des parties prenantes peut passer à côté. Zappez l’équipe support client et vous pourriez oublier « L’appareil doit fournir un mécanisme de reset pour restaurer les paramètres d’usine » — important pour le dépannage. Zappez la fabrication et vous pourriez spécifier une conception trop coûteuse ou trop difficile à produire en volume.

L’implication précoce crée aussi l’adhésion. Quand les gens voient leurs préoccupations traitées dans les exigences, ils soutiennent le projet, et moins de surprises remontent plus tard. Les parties prenantes apportent de l’expérience — l’utiliser maintenant évite des changements douloureux en aval.

À mesure que ces entrées s’accumulent, l’image des exigences fonctionnelles, non fonctionnelles et d’interface nécessaires prend forme. Cette étape consiste essentiellement à combler le fossé entre une idée prometteuse et un produit clairement défini : des souhaits flous (« Il faut que ce soit pas cher ! Il faut que ce soit sécurisé ! Il faut que ça fasse X et Y ! ») deviennent des exigences précises avec lesquelles les ingénieurs peuvent travailler, en parlant aux bonnes personnes et en posant les bonnes questions.

La collecte des exigences est un sport d’équipe. Rassemblez les acteurs clés dans la pièce — littéralement ou figurativement — et défrichez ce que l’appareil doit faire. Plus vous incorporez de points de vue maintenant, moins vous porterez d’angles morts dans les étapes suivantes.

Documenter et suivre les exigences

Une fois rassemblées, les exigences doivent être écrites clairement et organisées. Un enregistrement bien structuré garde tout le monde sur la même page et garantit que rien ne se perd. En pratique, les équipes utilisent différentes méthodes :

• Document d’exigences formel : beaucoup de projets créent une System Requirements Specification (SRS) ou un Product Requirements Document (PRD) — un document structuré (suivant parfois des normes comme l’IEEE 29148) où chaque exigence est listée, souvent avec un identifiant unique (p. ex. REQ-001 : L’appareil doit faire X). Les documents formels conviennent aux industries où une traçabilité stricte est nécessaire : aérospatiale, automobile, dispositifs médicaux.
• Backlog Agile (user stories) : certaines équipes, surtout agiles, capturent les exigences en user stories, epics, ou éléments dans un outil comme Jira ou un wiki. Par exemple : « En tant que propriétaire, je veux que le capteur m’alerte quand la température de ma maison dépasse 30 °C pour que je puisse allumer la clim. » Une story comme celle-ci se décompose en exigences spécifiques pour l’équipe d’ingénierie (une exigence fonctionnelle pour une alerte de surtempérature, par exemple). Les formats agiles sont plus libres, mais les exigences sous-jacentes doivent quand même être spécifiques et testables.

Quel que soit le format choisi, gardez chaque exigence sans ambiguïté et testable. Évitez les mots vagues comme « optimal », « convivial » ou « suffisant » sans quantification ; utilisez des chiffres concrets ou des critères clairs. Au lieu de « l’autonomie de la batterie devrait être longue », écrivez « l’autonomie de la batterie doit être d’au moins 12 mois sur une seule charge avec des téléversements de données horaires. » Voilà une cible vers laquelle les concepteurs peuvent travailler, sans devinettes.

Autre habitude utile : étiquetez chaque exigence avec la façon dont vous la vérifierez plus tard — anticipez comment vous prouverez que le produit y répond. Méthodes de vérification courantes :

• Test : tester directement l’appareil contre l’exigence. (P. ex. mesurer combien de temps il fonctionne sur batterie pour vérifier l’autonomie de 12 mois.)
• Analyse : utiliser des calculs ou des simulations. (P. ex. analyser les algorithmes de chiffrement contre les exigences de sécurité, ou calculer la consommation pour estimer l’autonomie.)
• Inspection : vérifier en observant ou en mesurant le produit fini. (P. ex. mesurer les dimensions de l’appareil au pied à coulisse contre l’exigence de taille, ou inspecter le PCB pour le vernis de conformité appliqué pour l’étanchéité.)
• Certification/Démonstration : vérifier par certification ou conformité démontrée. (P. ex. envoyer l’appareil à un laboratoire pour certifier qu’il répond aux normes réglementaires FCC/CE, ou mener un test d’infiltration d’eau pour démontrer l’exigence IP67.)

Étiqueter la méthode de vérification en amont — certaines équipes ajoutent une colonne « Méthode de vérification » au document d’exigences — force chaque exigence à être formulée de façon à pouvoir être prouvée plus tard. Cela vous épargne aussi le moment de la phase de test où quelqu’un demande : « Attendez, comment vérifie-t-on qu’on a atteint cet objectif vague ? »

Enfin, gardez le document d’exigences à jour. À mesure que le projet évolue, vous pouvez affiner ou ajouter des exigences (idéalement pas trop, si le travail initial a été minutieux). Une liste organisée et versionnée — même une simple feuille de calcul ou un document vivant — garde tout le monde aligné sur les exigences actuelles convenues, et aide les nouveaux membres de l’équipe à se mettre à niveau sur ce que le produit est censé faire.

En bref : ne gribouillez pas les exigences sur des post-it en espérant le meilleur. Écrivez-les de façon claire et structurée — un document formel ou un backlog bien entretenu. La clarté maintenant prévient la confusion plus tard, et planifier la vérification tôt pave la voie à une phase de test plus fluide.

Conclure l’Étape 1

Encore une fois, avant d’avancer : changer une exigence tardivement, c’est comme décider d’ajouter une chambre supplémentaire après la construction de la maison — possible, mais douloureux et coûteux. En IoT, « douloureux et coûteux » peut signifier un redesign complet du PCB parce qu’un capteur a été oublié, ou une refonte majeure du firmware parce qu’un cas d’usage n’a pas été considéré. Cela peut signifier des retards, des dépassements de budget, ou, au pire, un produit qui fait défaut à ses utilisateurs et à ses parties prenantes.

Investir l’effort maintenant pour capturer des exigences claires des parties prenantes et du système donne au projet son plan et sa feuille de route. Les exigences deviennent le point de référence pour tous les impliqués :

• Les ingénieurs matériel les utilisent pour choisir les composants et concevoir des circuits qui répondent aux specs.
• Les développeurs logiciel et firmware écrivent du code pour implémenter les fonctions et performances spécifiées.
• Les testeurs créent des plans de test directement à partir des exigences — chaque exigence vérifiable se traduit naturellement en un ou plusieurs cas de test.
• Les chefs de projet suivent l’avancement en cochant les exigences remplies et en s’assurant que rien de critique n’est abandonné.
• Les parties prenantes obtiennent une vue transparente de ce que le produit fera — et ne fera pas.

Quand des désaccords ou de nouvelles idées apparaissent plus tard, le document d’exigences est l’étoile du berger qui garde l’équipe alignée. Si quelqu’un propose du feature creep à mi-développement, vous pouvez demander : « Est-ce dans le périmètre selon nos exigences convenues ? Sinon, qu’échange-t-on pour l’ajouter ? »

Alors prenez le temps de bien faire l’Étape 1. Faites venir les parties prenantes, réfléchissez aux fonctions et contraintes, écrivez tout clairement, et revérifiez que l’ensemble se tient. Itérer sur une spécification coûte bien moins cher qu’itérer sur un appareil physique ou une base de code. Faites bien cette étape, et vous préparez chaque étape qui suit.

Avec un ensemble solide d’exigences des parties prenantes et du système en main, vous êtes prêt à avancer vers la conception et la construction de quelque chose qui y répond. Et ce faisant, vous portez la carte avec vous — les priorités d’abord, bien faites.