Migration passerelle Linux ouvert

L'exploitant gérait une flotte sur des passerelles propriétaires fermées avec un firmware verrouillé. Le fournisseur contrôlait la cadence des versions, les intégrations supportées et, parce que le firmware était une boîte noire, la posture de sécurité de chaque appareil sur le terrain. Pression sur les prix, signaux de fin de vie de la part du fournisseur et impossibilité de mener un véritable audit avaient fait passer la migration de « nice to have » à « ce trimestre ».

La cible de la migration était une passerelle Linux ouverte avec logiciel embarqué entièrement possédé par l'exploitant, déployée par étapes avec un chemin de rollback, et livrée avec la documentation permettant à l'exploitant d'étendre la pile sans nous.

Vendor lock-in. Le firmware constituait une dépendance mono-fournisseur pour les mises à jour, le support et toute nouvelle fonctionnalité. Il fallait que la pile post-migration soit portable entre classes matérielles et libre de goulots d'étranglement mono-fournisseur dans le logiciel.

Angles morts de sécurité. Le firmware fermé ne pouvait pas être audité. Le remplacement devait être reproductible depuis les sources, signé et vérifiable de bout en bout, pour que sécurité et conformité disposent d'un artefact réel à examiner.

Risque de fin de vie. L'ancien matériel était sur une trajectoire de retrait sans plan de mise à niveau. Nous avons conçu la migration pour que l'exploitant puisse continuer à déployer de nouvelles unités sans rouvrir notre contrat.

La nouvelle pile s'appuie sur des passerelles Linux ouvertes Owasys avec une image reproductible construite via alloy-it. L'image regroupe la couche d'acquisition, un schéma de télémétrie par actif et l'agent OTA contrôlé par l'exploitant. Tout ce qui tourne sur l'appareil est visible au niveau source dans le compte de l'exploitant.

La télémétrie circule en MQTT vers un broker hébergé par l'exploitant, puis dans son outillage analytique et de dispatching existant. Le cloud du fournisseur fermé sort du périmètre post-migration ; le VPC de l'exploitant est le foyer opérationnel des données.

Point critique : la nouvelle image émet des enregistrements sur le même schéma canonique que les unités héritées dès que les deux peuvent être lus en parallèle, afin que les tableaux de bord ne se cassent pas pendant le déploiement. La réconciliation de schéma s'opère au bord, pas dans douze couches de transformations cloud.

Audit (semaines 1–3) : nous avons cartographié chaque capacité du firmware hérité, protocoles, intégrations, alertes, canaux OTA, et produit une matrice de parité fonctionnelle validée par le lead engineering de l'exploitant avant la moindre ligne de code.

Firmware sur mesure (semaines 4–10) : alloy-it a produit des builds reproductibles de la nouvelle image. Nous avons répliqué la matrice ligne par ligne et ajouté deux capacités que le firmware hérité n'avait jamais : la mise en tampon au bord sur des coupures de plusieurs heures et le rollback OTA par hash d'image.

Déploiement par étapes (semaines 11–20) : migration par vagues, avec rollback vers le firmware hérité disponible à chaque étape. Chaque vague a tourné 72 heures en double émission afin que les tableaux de bord voient les deux flux et que l'exploitant puisse comparer.

Transfert IP (semaine 21) : l'exploitant a reçu les sources de l'image de passerelle, la pipeline de build alloy-it, l'infrastructure OTA en tant que code et les runbooks. Notre contrat a pris fin ; sa pile, non.

Le chiffre vedette, flotte sur matériel ouvert, sans vendor lock, compte, mais deux changements opérationnels pèsent davantage.

• L'exploitant livre désormais ses propres mises à jour de passerelle. Les fenêtres OTA sont planifiées par son équipe, pas par la roadmap du fournisseur. Les nouvelles fonctionnalités appareil arrivent en jours, pas en trimestres.
• La sécurité dispose enfin d'artefacts. Builds reproductibles, images signées, chaîne d'approvisionnement vérifiable. L'équipe sécurité a cessé de décrire le parc de passerelles comme une boîte noire.

C'est la forme standard de migration pour tout exploitant disposant d'un parc de passerelles fermé qui doit devenir ouvert sans perturber les opérations : audit de parité fonctionnelle d'abord, build d'image reproductible, déploiement en double émission, transfert de propriété intellectuelle à la fin. Le fournisseur matériel change, l'exploitant reste, avec la pile qui lui appartient désormais.