Comment sélectionner un partenaire de développement spécialisé dans les systèmes embarqués et l'Internet des objets (IoT)

Un fondateur d'entreprise de matériel informatique disposant d'un prototype fonctionnel et soumis à une échéance de fabrication se pose une question cruciale avant de signer un contrat d'ingénierie : cette équipe est-elle réellement capable de faire passer un produit connecté du stade de la maquette au stade d'un appareil certifié et prêt à être commercialisé ? Un responsable d’ingénierie chargé d’intégrer des capteurs IoT à une machine existante se pose une version plus ciblée de cette même question, en cherchant à savoir si le partenaire maîtrise à la fois le matériel physique et la plateforme cloud sur laquelle les données seront finalement stockées.

Le développement de systèmes embarqués et de l’IoT se situe à la croisée de plusieurs disciplines d’ingénierie à la fois : conception matérielle, micrologiciels, connectivité sans fil, infrastructure cloud et, souvent, conception mécanique des boîtiers. Évaluer un partenaire pour ce type de projet implique de vérifier qu’il dispose d’une expertise réelle et vérifiable sur l’ensemble de cette pile technologique, et pas seulement d’un portefeuille de logos. Ce guide présente en détail ce qu’impliquent réellement le développement embarqué et l’IoT, les critères spécifiques qui permettent de distinguer un partenaire compétent d’un partenaire à risque, ainsi que les questions qu’il convient de poser avant de confier un budget et une feuille de route produit à une équipe externe. Monarch Innovation collabore avec des équipes matérielles et produit dans le cadre précisément de ce type d’ingénierie pluridisciplinaire, et c’est autour de cette perspective que s’articule ce guide.

01Ce que recouvrent réellement le développement des systèmes embarqués et de l'IoT

Le développement de systèmes embarqués consiste à concevoir et à programmer des logiciels qui s'exécutent directement sur un matériel, en contrôlant la manière dont un appareil détecte, traite et réagit en temps réel. Il se distingue du développement d'applications générales car il doit s'adapter à des contraintes fixes en matière de mémoire, de consommation d'énergie et de puissance de calcul, et parce que les bugs peuvent affecter le comportement physique de l'appareil plutôt que de se limiter à l'affichage à l'écran.

Le développement de l’IoT étend ce même travail d’embarqué vers l’extérieur, en connectant un appareil à un réseau afin qu’il puisse envoyer des données vers le cloud, recevoir des commandes et interagir avec d’autres systèmes. Un produit IoT complet s'articule généralement autour de quatre couches : le matériel lui-même, le micrologiciel qui y est exécuté, la couche de connectivité qui assure l'entrée et la sortie des données de l'appareil, et le cloud ou la plateforme backend qui stocke, traite et affiche ces données.

Un partenaire qui excelle dans un domaine n'est pas forcément performant dans les quatre. De nombreuses entreprises spécialisées dans les logiciels embarqués développent d'excellents micrologiciels, mais sous-traitent la conception matérielle à des tiers, et de nombreux fournisseurs d'IoT axés sur le cloud disposent d'une expertise matérielle interne très limitée, voire inexistante. Les services d’ingénierie produit de Monarch Innovation couvrent la conception matérielle et électrique, les systèmes embarqués et le développement IoT en tant que disciplines interdépendantes plutôt que comme des étapes distinctes, ce qui constitue l’un des premiers éléments à vérifier chez tout partenaire que vous évaluez.

02Pourquoi les entreprises externalisent-elles le développement de systèmes embarqués et de l'IoT ?

Plusieurs contraintes récurrentes poussent les équipes chargées du matériel et des produits à se tourner vers un partenaire technique externe plutôt que de développer chaque couche en interne.

• Lacunes en matière de compétences interdisciplinaires : une équipe axée sur le logiciel qui développe un produit connecté dispose souvent de solides compétences en matière de micrologiciels ou de cloud, mais n'a aucune expérience en interne en conception matérielle ou de circuits imprimés ; l'inverse est tout aussi courant pour les équipes axées sur le matériel.
• Une expertise spécialisée et ponctuelle : un produit donné peut nécessiter un protocole sans fil spécifique, une gamme particulière de microcontrôleurs ou une procédure de certification avec laquelle l'équipe interne n'a jamais travaillé auparavant et dont elle n'aura plus besoin avant plusieurs années.
• Rapidité de mise en place d’une solution opérationnelle : le recrutement et la mise en place en interne d’une équipe complète spécialisée dans l’embarqué et l’IoT peuvent prendre plus de temps que ne le permet la feuille de route du produit, en particulier lorsque le développement du matériel et du micrologiciel doit se faire en parallèle.
• Pression liée à la certification et à la conformité : pour qu'un appareil connecté passe avec succès les tests FCC, CE ou UL, il est nécessaire de prendre des décisions de conception dès le début du projet ; faire appel à un partenaire ayant déjà suivi ce processus permet d'éviter des modifications de conception coûteuses en fin de projet.

En contrepartie, les projets liés à l'informatique embarquée et à l'IoT sont plus difficiles à transférer que les projets classiques d'externalisation logicielle. Une base de code de micrologiciel liée à un matériel spécifique, ou une architecture cloud construite selon les conventions d’un partenaire, peut s’avérer coûteuse à transférer à une deuxième équipe si la première ne donne pas satisfaction. C’est pourquoi le choix du partenaire revêt ici une importance plus grande que dans les travaux d’ingénierie moins dépendants du matériel.

03Les critères à prendre en compte pour choisir un partenaire de développement de systèmes embarqués et d'Internet des objets (IoT)

Une fois que vous savez de quelles couches votre produit a besoin, évaluez un partenaire potentiel à l'aune de critères spécifiques et vérifiables, plutôt qu'en vous basant sur une impression générale issue d'un entretien commercial.

Couverture pluridisciplinaire : demandez directement si les ingénieurs spécialisés dans le matériel, les micrologiciels, la connectivité et le cloud travaillent ensemble sur le même projet ou s’ils sont sous-traités séparément. Une équipe qui conçoit ensemble le circuit imprimé et écrit le micrologiciel a tendance à détecter les problèmes d’intégration, tels qu’un capteur consommant plus d’énergie que ce pour quoi la carte a été conçue, avant même que ceux-ci n’apparaissent au stade du prototype.

Protocole et niveau de connectivité : assurez-vous que le partenaire dispose d’une expérience concrète et avérée avec la technologie sans fil spécifique dont votre produit a besoin, qu’il s’agisse du Bluetooth Low Energy pour un appareil portable alimenté par batterie, du LoRaWAN ou de la technologie cellulaire pour des capteurs industriels à longue portée, ou encore du Wi-Fi et du Zigbee pour les appareils domotiques. Chaque protocole présente des compromis différents en termes de consommation, de portée et de coût, et un partenaire doit être en mesure d’expliquer pourquoi l’un d’entre eux correspond mieux à votre cas d’utilisation qu’un autre, plutôt que de se rabattre par défaut sur celui qu’il connaît le mieux.

Pratiques de sécurité pour les appareils connectés : un produit connecté est également un terminal réseau, et une sécurité insuffisante de l’appareil peut exposer l’ensemble du parc à des attaques. Les recommandations de l’Institut national des normes et des technologies (NIST) en matière de cybersécurité de l’IoT décrivent les pratiques de base que les fabricants devraient intégrer à un appareil dès la phase de conception, notamment l’identification sécurisée, la protection des données et les mécanismes de mise à jour. Demandez à un partenaire potentiel comment il gère le démarrage sécurisé, les communications chiffrées et la signature des mises à jour en direct, et ne vous contentez pas de lui demander s’il « prend la sécurité au sérieux ».

Accompagnement en matière de certification et de conformité : les appareils émettant des signaux radio doivent généralement obtenir la certification FCC aux États-Unis et le marquage CE en Europe ; pour de nombreuses catégories de produits, des tests de sécurité UL viennent s’ajouter à ces exigences. Un partenaire disposant d'une expérience directe en matière de tests de pré-conformité peut signaler des problèmes de conception, tels qu'un mauvais emplacement d'antenne ou une piste haute vitesse non blindée, plusieurs mois avant qu'un échec coûteux à la certification ne vienne autrement à la lumière.

Approvisionnement en composants et prise en compte de l'obsolescence : les délais de livraison des semi-conducteurs et l'arrêt de la production de certains composants peuvent retarder un projet matériel bien après la fin de la conception proprement dite. Un partenaire qui prend en compte les composants de deuxième source et des délais de livraison réalistes dès la phase de conception, et pas seulement lorsque la pénurie se fait sentir, réduit considérablement ce risque.

Expérience en matière d'intégration au cloud et au backend : si le produit nécessite un tableau de bord, des outils d'analyse ou une gestion de flotte, assurez-vous que le partenaire dispose d'une véritable expérience dans la connexion d'appareils embarqués à une plateforme cloud, notamment en matière de mise en service d'appareils à grande échelle et de gestion en douceur des coupures de connexion, plutôt que de se contenter de développer la partie « appareil » et de considérer le cloud comme un problème qui ne le concerne pas.

Modèle de dotation en personnel et ingénieurs désignés : demandez précisément qui travaillera sur le projet et si ces ingénieurs resteront affectés aux phases de matériel, de micrologiciel et de connectivité. La continuité est plus importante dans le domaine de l’embarqué que dans la plupart des projets logiciels, car un changement d’ingénieur en cours de projet implique souvent de réapprendre de zéro à la fois les contraintes matérielles et l’architecture du micrologiciel. Le guide précédent de Monarch Innovation, qui compare le renforcement des effectifs à une équipe d’ingénieurs dédiée, aborde cette question de dotation en personnel de manière plus approfondie pour les équipes qui évaluent quel modèle convient le mieux à un programme matériel en cours.

Protection de la propriété intellectuelle : les produits embarqués et IoT recèlent souvent une réelle valeur concurrentielle dans leur micrologiciel et leur architecture système. Renseignez-vous précisément sur la manière dont le partenaire gère la propriété du code source, les contrôles d'accès et la confidentialité, et obtenez par écrit les conditions de cession de la propriété intellectuelle avant le début des travaux de conception.

Pratiques en matière de documentation et de transfert : vérifiez bien ce que vous recevez à la fin du projet : schémas, fichiers de conception des circuits imprimés, code source du micrologiciel accompagné de commentaires, rapports de test et documentation de certification. Un partenaire incapable de décrire clairement son processus de transfert est un partenaire dont vous aurez peut-être du mal à vous séparer par la suite, même si le travail d'ingénierie en lui-même est de qualité.

04Liste de contrôle pour l'évaluation des partenaires dans les domaines de l'informatique embarquée et de l'IoT

05Questions à poser avant de signer un contrat

Une série de questions brèves et directes posées lors de l'évaluation permet de mettre en évidence la plupart des risques avant qu'ils ne se transforment en problèmes contractuels.

1. Quels ingénieurs, précisément, travailleront sur notre matériel, notre micrologiciel et notre connectivité, et resteront-ils affectés à ce projet pendant toute la durée du programme ?
2. Quels protocoles sans fil et quelles plateformes cloud avez-vous mis en production, et pas seulement sous forme de prototypes ?
3. Comment gérez-vous la sécurité des appareils, notamment le démarrage sécurisé, les communications cryptées et l'intégrité des mises à jour OTA ?
4. Quelle est votre expérience en matière de certifications FCC, CE ou UL, et pourriez-vous nous présenter un projet similaire ?
5. Comment tenez-vous compte des délais d'approvisionnement des composants et de la recherche de sources d'approvisionnement alternatives dès la phase de conception, et pas seulement après l'apparition d'une pénurie ?
6. De quels codes sources, schémas et documents disposerons-nous à la fin du projet, et sous quel format ?
7. Comment coordonnez-vous les équipes chargées du matériel, des micrologiciels et du cloud si elles ne sont pas composées des mêmes personnes ?
8. Pourriez-vous nous donner des exemples de produits ayant atteint le stade de la production et de la certification, et pas seulement de prototypes fonctionnels ?

Un partenaire qui répond à ces questions de manière concrète, plutôt qu’en se contentant de vous rassurer de manière générale, est généralement le choix le plus sûr.

06Erreurs courantes lors de l'externalisation du développement de systèmes embarqués et de l'IoT

Une poignée de schémas récurrents se dessinent lorsque l’externalisation des solutions embarquées et de l’IoT tourne mal. La séparation du matériel et du micrologiciel entre deux fournisseurs sans lien entre eux est l’un des cas les plus courants, car les problèmes d’intégration n’apparaissent alors qu’à un stade avancé et aucune des deux équipes n’assume pleinement la responsabilité de la correction. Le choix d’un partenaire sur la base d’une démonstration convaincante de sa plateforme cloud, sans tenir compte de son expérience réelle en matière de matériel et de certification, en est une autre, en particulier pour les produits où l’appareil physique porte l’essentiel du risque technique. Le fait de reporter toute discussion sérieuse sur la sécurité jusqu’à la fin de la conception entraîne souvent des retouches coûteuses, car le démarrage sécurisé et les communications chiffrées sont bien plus difficiles à intégrer a posteriori qu’à prévoir dès le départ. Sous-estimer les délais de certification constitue une quatrième erreur : une entreprise considère alors les tests FCC ou CE comme une simple formalité finale plutôt que comme un processus devant orienter les décisions de conception plusieurs mois à l’avance. Enfin, laisser en suspens la question de la propriété de la propriété intellectuelle et du transfert de la documentation jusqu’à la fin de la mission engendre précisément le type de problème de dépendance que l’externalisation était censée éviter.

07Développer un produit connecté avec le bon partenaire technique

Le succès ou l’échec du développement de systèmes embarqués et de l’IoT dépend davantage de la qualité du partenaire qui les soutient que dans la plupart des autres types d’externalisation d’ingénierie. Le travail couvre des domaines tels que le matériel, les micrologiciels, la connectivité et le cloud, qui sont rarement regroupés sous un même toit, et un maillon faible dans l’un d’entre eux peut bloquer un produit bien après la signature du contrat. Vérifier la couverture multidisciplinaire réelle, l’expérience en matière de sécurité et de certification, la maîtrise de l’approvisionnement en composants, ainsi que la clarté des conditions relatives à la propriété intellectuelle et à la documentation : voilà ce qui fait la différence entre un parcours sans encombre vers la production et un programme qui s’enlise au stade des tests.

Monarch Innovation accompagne les équipes chargées du matériel et des produits dans les domaines de la conception mécanique, de l'ingénierie matérielle et électrique, des systèmes embarqués et du développement de l'IoT, en servant de point de contact unique pour des disciplines souvent réparties entre différents prestataires. Si vous envisagez de développer un produit connecté et que vous vous demandez si votre équipe dispose en interne de toutes les compétences nécessaires, contactez Monarch Innovation afin de discuter de vos besoins en matière de matériel, de micrologiciel et de connectivité avec notre équipe d'ingénieurs.

08Discutez avec un expert en systèmes embarqués et en Internet des objets (IoT)

Vous développez un produit connecté et avez besoin d'une expertise en matière de matériel, de micrologiciels ou d'intégration cloud ? Contactez Monarch Innovation pour discuter avec notre équipe d'ingénieurs de vos besoins en matière de systèmes embarqués ou de développement IoT.

09Foire aux questions

1. En quoi consiste exactement le métier d'un partenaire spécialisé dans le développement de systèmes embarqués et de l'Internet des objets (IoT) ?

Un partenaire spécialisé dans le développement de systèmes embarqués et de l'Internet des objets (IoT) conçoit et réalise le matériel, le micrologiciel, la connectivité et, souvent, l'intégration au cloud d'un produit connecté. Cela peut concerner une seule couche, comme le micrologiciel d'un circuit imprimé existant, ou l'ensemble de la pile, de la conception du circuit imprimé jusqu'aux tableaux de bord dans le cloud, en fonction de ce dont disposent déjà le produit et l'équipe interne.

2. Comment évaluer un partenaire d'externalisation spécialisé dans les systèmes embarqués ?

Vérifiez que le prestataire dispose d’une expérience concrète et avérée dans les domaines spécifiques requis par votre produit, notamment le matériel, les micrologiciels, le protocole sans fil précis utilisé et, le cas échéant, l’intégration au cloud. Renseignez-vous sur les pratiques en matière de sécurité, l’historique des certifications (FCC, CE ou UL), la stratégie d’approvisionnement en composants, ainsi que sur la documentation et le code source qui vous seront remis à la fin du projet.

3. Pourquoi l'externalisation dans le domaine des systèmes embarqués et de l'IoT présente-t-elle plus de risques que l'externalisation logicielle classique ?

Les produits embarqués et IoT lient étroitement le micrologiciel à un matériel spécifique ; il est donc plus difficile de remplacer un partenaire peu performant en cours de projet que dans la plupart des projets logiciels. Les exigences de certification, les délais d'approvisionnement des composants et les cycles de prototypage physique ajoutent également des risques et des coûts qui n'existent pas dans le cadre d'une externalisation purement logicielle.

4. Quelles sont les normes de sécurité applicables au développement des appareils connectés ?

L'Institut national des normes et des technologies (NIST) publie des recommandations fondamentales en matière de cybersécurité à l'intention des fabricants d'appareils connectés (IoT), qui portent notamment sur des pratiques telles que l'identification sécurisée des appareils, la protection des données et les mécanismes de mise à jour sécurisés. Un partenaire de développement compétent doit être capable d'expliquer concrètement comment son processus de conception tient compte de ces pratiques, plutôt que de considérer la sécurité comme un élément secondaire.

5. Tous les produits IoT doivent-ils être certifiés FCC ou CE ?

La plupart des appareils émettant des signaux radio doivent être certifiés FCC aux États-Unis et porter le marquage CE en Europe ; de nombreuses catégories de produits doivent également faire l'objet de tests de sécurité UL. Les exigences varient en fonction du type d'appareil et du marché cible ; il est donc utile de déterminer dès le début du processus de conception la procédure de certification exacte à suivre afin d'éviter de devoir revoir la conception à un stade avancé.

6. Vaut-il mieux faire appel à un seul partenaire pour le matériel, les micrologiciels et le cloud, ou à des spécialistes distincts ?

Le fait qu’un seul partenaire couvre les trois niveaux au sein d’une même équipe permet généralement de réduire les erreurs d’intégration et les accusations mutuelles lorsque quelque chose ne fonctionne pas comme prévu. Le recours à des spécialistes distincts peut tout de même bien fonctionner si l’entreprise dispose d’une solide direction technique interne capable de coordonner les passerelles entre eux, mais cette charge de coordination doit être anticipée dès le départ plutôt que découverte en cours de projet.

7. Quelles questions dois-je poser concernant la propriété intellectuelle avant de choisir un partenaire de développement embarqué ?

Demandez directement au partenaire comment il gère la propriété du code source, les contrôles d'accès pendant le développement, et quelles sont les clauses relatives à la cession de la propriété intellectuelle figurant dans le contrat. Obtenez ces clauses par écrit avant le début des travaux de conception, car les produits embarqués et IoT recèlent souvent une valeur concurrentielle importante dans leur micrologiciel et leur architecture système.