Du logiciel embarqué qui tient sur le terrain.
Développement de firmware et de systèmes embarqués en C/C++ pour STM32, Atmel/Microchip et plateformes BLE — couches HAL et drivers, applications RTOS, objets connectés pour l'automobile et l'IoT. En nearshore depuis Tunis pour les entreprises en France et en Europe.
Firmware & HAL
Firmware bare-metal et RTOS en C/C++ sur microcontrôleurs STM32 et Atmel/Microchip. Nous développons et maintenons des couches d'abstraction matérielle et des drivers (UART, SPI, I2C, CAN) qui gardent le code applicatif portable.
Objets connectés & BLE
Développement Bluetooth Low Energy et produits connectés de bout en bout : la pile embarquée, l'application mobile compagnon (Flutter) et le backend cloud — une seule équipe du device au cloud.
Automobile & industriel
Développement embarqué aux exigences automobiles et industrielles : comportement déterministe, watchdogs et modes dégradés, diagnostics, et stratégies de mise à jour OTA sans risque pour le parc.
Tests & bring-up matériel
Bring-up de cartes, bancs de test hardware-in-the-loop et drivers testés unitairement — les régressions se détectent au labo, pas chez le client.
Les questions qui précèdent un contrat.
- Sur quelles parties d'un produit embarqué intervenez-vous ?
- Le logiciel : firmware sur microcontrôleur en C et C++, avec ou sans RTOS ; Linux embarqué avec Yocto ou Buildroot et les pilotes autour ; la connectivité en BLE, Wi-Fi, liaison série ou MQTT ; et l'application compagnon et la partie cloud quand l'appareil en a besoin. Nous travaillons à partir de vos schémas, de vos datasheets et de vos exigences.
- Concevez-vous aussi le matériel ?
- Non. Nous écrivons le logiciel et travaillons avec vos électroniciens ou votre fabricant, ce qui nous permet de relire un schéma du point de vue du firmware et de demander tôt les points de test et le connecteur de debug. Choisir un partenaire qui ne fait que du logiciel signifie aussi que nous n'avons aucun intérêt dans la carte que vous fabriquez.
- Comment testez-vous du firmware sans avoir le matériel ?
- Nous séparons la logique du matériel derrière une couche d'abstraction : le code de protocole et les machines à états sont testés unitairement sur poste. Tout ce qui dépend du timing ou des périphériques tourne sur cartes réelles au banc, et c'est pourquoi il nous faut au moins un exemplaire tôt. Quand le volume le justifie, nous montons un banc de test automatisé avec le matériel dans la boucle.
- Les appareils pourront-ils être mis à jour sur le terrain ?
- Oui, et cela se conçoit dès le départ plutôt que de s'ajouter après. Cela suppose des images signées, un schéma de partitions A/B ou équivalent avec retour arrière automatique, des transferts reprenables sur une liaison peu fiable, et un démarrage sécurisé si le modèle de menace l'exige. Ajouter la mise à jour à distance à un produit déjà expédié coûte cher, quand c'est encore possible.
- Pouvez-vous nous aider pour la certification et les audits ?
- Nous produisons ce que le volet logiciel d'un audit demande : traçabilité des exigences, documentation de conception et d'interfaces, preuves de test, rapports d'analyse statique et de conformité aux règles de codage, et l'historique des versions. La certification elle-même est délivrée par votre organisme notifié ou votre laboratoire, pas par nous, et nous ne prétendons pas le contraire.
- Comment se déroule la collaboration, et à qui appartient le firmware ?
- Les sources, la configuration de la chaîne d'outils et les scripts de build sont à vous, dans un dépôt que vous contrôlez. Nous sommes à Tunis en UTC+1, la journée se superpose entièrement à celle des équipes européennes, les échanges se font en anglais, en français ou en arabe, et vous avez une démonstration sur matériel réel à la fin de chaque sprint plutôt qu'un rapport d'avancement.