Reprendre la maintenance d'un produit électronique développé par un autre prestataire : par où commencer ?

Commencez par récupérer tout ce qui permet de reconstruire le produit : code source, outils de build, fichiers de fabrication, documentation et accès aux serveurs. Faites ensuite auditer cet ensemble pour savoir ce qui fonctionne, ce qui manque et ce qui est fragile. Les corrections viennent après, par petites versions testées sur le produit réel.

Que faut-il récupérer auprès de l'ancien prestataire ?

Tout ce qui permet de reconstruire et de livrer le produit sans lui :

• le code source complet du firmware, des applications et des serveurs, avec son historique si possible ;
• les outils de build : compilateur et version, scripts, dépendances, clés de signature des mises à jour ;
• les fichiers de la carte électronique : schémas, routage, nomenclature, dossier de fabrication ;
• la documentation : architecture, protocoles, procédures de test et de mise en production ;
• les accès : dépôts de code, serveurs, comptes des magasins d'applications, noms de domaine.

Vérifiez ce que votre contrat prévoit sur la propriété et la remise de ces éléments. Pour un cas précis, demandez conseil à votre juriste.

Comment savoir si le code récupéré est complet ?

En le reconstruisant. Un firmware compilé à partir des sources récupérées, puis chargé sur une carte et testé, prouve que rien d'essentiel ne manque. S'il ne compile pas, ou si le comportement diffère de celui du produit en service, il manque une pièce : une dépendance, une option de build, une version plus récente du code.

Que doit contenir l'audit ?

• L'état du code : structure, dette technique, parties fragiles ou non documentées.
• L'état des outils : build reproductible ou non, tests existants, intégration continue.
• La sécurité : dépendances obsolètes, mises à jour, gestion des clés.
• Les composants : ceux qui approchent de leur fin de vie.
• Une liste de priorités, avec ce qui est urgent et ce qui peut attendre.

Par quoi commencer les corrections ?

Par une première version qui ne change presque rien : elle valide toute la chaîne, du build à la mise à jour des produits en service. Viennent ensuite les bugs les plus gênants pour vos clients, puis les évolutions. Chaque version est testée sur le produit réel avant d'être livrée.

Faut-il réécrire le produit ?

Rarement d'emblée. Un code existant qui fonctionne en production a une valeur : il contient des cas réels traités au fil du temps. Une refonte progressive, partie par partie, limite les risques. La réécriture complète se justifie quand l'audit montre que la base ne permet plus d'évoluer.

Notre accompagnement

Picodev reprend des produits développés par d'autres équipes : audit, maintenance corrective et évolutive, mises à jour de sécurité, obsolescence des composants.

Service associé : Maintenance et reprise