- 01Commit
- 02Build & analyse
- 03Banc HIL
- 04Mesures
- 05Analyse IA
- 06Correctif validé
Chaque commit repart avec une mesure, pas avec une opinion.
Six étapes s'enchaînent sans intervention manuelle. L'IA propose, nos ingénieurs relisent et valident chaque correctif.
Quand tester à la main ne suffit plus.
Votre firmware régresse d'une version à l'autre
Une correction casse une fonction qui marchait. La chaîne rejoue tous les tests sur la carte à chaque modification : le défaut apparaît avec la modification qui l'a introduit.
Vos essais sur carte sont manuels
Flasher, brancher, mesurer, noter : ces gestes prennent du temps d'ingénieur et ne sont jamais refaits à l'identique. Le banc les exécute seul, de la même façon à chaque fois.
Vous préparez votre conformité RED ou CRA
Ces textes demandent de tracer les composants du firmware et de livrer des mises à jour de sécurité. La chaîne produit ces éléments à chaque version.
Ce qui se passe entre un commit et un correctif.
Commit
Chaque modification du code déclenche la chaîne, sans action manuelle.
Build & analyse
Le firmware est compilé dans un environnement figé, puis passé à l'analyse statique. Le même code donne toujours le même binaire.
Banc HIL
Le binaire est chargé sur votre vraie carte. Le banc simule ce qui l'entoure : capteurs, interfaces, réseau.
Mesures
Le banc relève le comportement de la carte, par exemple la radio et la consommation, et le compare aux versions précédentes.
Analyse IA
L'IA trie les journaux, repère les régressions et prépare un correctif avec les tests qui le vérifient.
Correctif validé
Un ingénieur Picodev relit le correctif. Une fois validé, il repart dans la boucle comme n'importe quelle modification.
Trois briques, une seule chaîne.
Usine logicielle
CI/CD firmware, builds reproductibles, analyse statique, pipeline OTA signé, SBOM.
Bancs automatisés
Bancs HIL pilotés par la CI, mesures radio et consommation, bancs de production.
Amélioration continue
Génération de tests, tri des logs, détection des régressions, correctifs relus par nos ingénieurs.
La chaîne logicielle
Elle s'intègre à votre forge, par exemple GitHub Actions. Elle compile de façon reproductible, analyse le code, signe les mises à jour OTA et tient à jour l'inventaire des composants (SBOM). Nous la mettons en place sur les cibles que nous pratiquons, comme Zephyr, FreeRTOS, STM32, ESP32 ou nRF, avec MCUboot pour les mises à jour.
Un banc conçu pour votre produit
Chaque banc est conçu sur mesure. Selon le produit et le budget, il va d'un simulateur d'interfaces à un banc complet avec ses équipements de mesure. Nous retenons avec vous le niveau qui a du sens pour votre produit.
Une IA choisie avec vous
Les modèles peuvent être ceux d'un fournisseur ou tourner en local. En local, il faut un matériel adapté pour qu'ils restent efficaces. Dans les deux cas, un ingénieur relit chaque correctif.
Des preuves à chaque version.
Chaque version livrée est accompagnée des éléments qui permettent de la tracer.
- 01
Rapport de version
Ce qui a changé, ce qui a été testé sur le banc, et le résultat de chaque test.
- 02
SBOM
L'inventaire des composants logiciels de votre firmware, tenu à jour à chaque build.
- 03
Preuves RED / CRA
Les traces de tests et de mises à jour utiles à votre dossier de conformité.
Un audit d'abord, la chaîne ensuite.
Audit
Nous faisons l'état des lieux de votre chaîne de test et de ce qui peut être automatisé.
Conception
Nous définissons la chaîne et le banc adaptés à votre produit et à votre budget.
Mise en place
La chaîne tourne sur un nouveau firmware conçu pour elle, ou sur votre firmware existant, que nous reprenons.
Transfert
Vous recevez la documentation technique du banc. Vous pouvez acquérir le banc et reprendre la chaîne en interne.
Avant de nous confier votre firmware.
Par quoi commence-t-on ?
Par un audit. Il fait l'état des lieux de votre chaîne de test et de ce qui peut être automatisé.
La chaîne fonctionne-t-elle sur un firmware existant ?
Oui. Elle est pensée pour les nouveaux firmwares, conçus dans cette optique, et permet aussi de reprendre rapidement un firmware existant.
À quoi ressemble un banc ?
Chaque banc est conçu sur mesure pour le produit. Certains se limitent à un simulateur d'interfaces, d'autres embarquent des équipements entiers. C'est une question de budget et de pertinence pour le produit.
Où tournent les bancs ?
Pendant le développement, les bancs tournent chez Picodev. Vous pouvez y accéder par VPN, sur demande. Ils peuvent ensuite vous être livrés.
À qui appartient le banc ?
Vous pouvez acquérir le banc matériel. Dans tous les cas, vous recevez la documentation technique qui permet de le reproduire.
Puis-je reprendre la chaîne en interne ?
Oui. La chaîne peut être reprise en interne par votre équipe.
Quelle place pour l'IA ?
L'IA génère des tests, trie les logs et détecte les régressions. Elle prépare les correctifs ; ils sont toujours relus par nos ingénieurs avant d'être validés.
Mon code source est-il envoyé à un tiers ?
C'est vous qui décidez. Les modèles peuvent être ceux d'un fournisseur ou tourner en local ; en local, il faut un matériel adapté pour qu'ils restent efficaces.
Quel gain attendre ?
Le gain porte sur deux points : le temps que vos ingénieurs ne passent plus à tester à la main, et les défauts détectés avant la livraison plutôt que chez vos clients. L'audit sert à l'estimer pour votre produit.
Commençons par un audit de votre chaîne de test.
Remplissez notre formulaire de projet ou écrivez-nous.