Reprendre un projet électronique en échec : diagnostic et plan de sauvetage

Quand un projet électronique tourne mal

Reprendre un projet électronique en échec consiste à auditer le travail existant et identifier les causes racines (Root Cause Analysis, RCA) plutôt que de repartir de zéro. Chez AESTECHNO, Montpellier, nous menons ces reprises avec une méthode en 5 phases, de l'audit schéma/PCB/firmware au respin pré-conforme CEM. Selon Pmi, près de 35 % des projets techniques complexes exigent une reprise structurée avant industrialisation.

D'après Mckinsey et selon Boston Consulting, le coût moyen d'un projet repris en cours dépasse de 40 % à 70 % celui d'un projet cadré dès le départ, comme le souligne Gartner dans ses analyses récentes de portefeuilles hardware (références : pmi.org, mckinsey.com, bcg.com, gartner.com).

Sommaire

• Les signes d'un projet en difficulté
• Pourquoi les projets électroniques échouent
• Notre méthodologie de reprise de projet
• Ce qu'on peut sauver vs ce qu'il faut refaire
• Comment éviter d'en arriver là
• Combien de temps dure une reprise de projet électronique ?
• En résumé
• Questions fréquentes

Vous avez investi des mois de développement, mobilisé un budget conséquent, et votre prestataire vous a livré un résultat qui ne fonctionne pas. Le prototype échoue aux tests, le firmware plante de manière intermittente, le PCB nécessite un respin complet. Peut-être que le produit "fonctionne sur le banc" mais s'effondre en conditions réelles, typiquement à -20 °C, sur une alimentation 12 V bruitée, ou face à une décharge ESD IEC 61000-4-2 à ±8 kV contact. Peut-être que la certification a révélé des non-conformités rédhibitoires sur la norme IEC EN 55011 (dépassement de plusieurs dB au-dessus de la limite 40 dBµV/m à 3 m).

Si vous êtes dans cette situation, sachez que vous n'êtes pas seul. L'échec d'un projet électronique confié à un prestataire externe est bien plus fréquent que ce que l'industrie veut bien admettre. La vraie question n'est pas "qu'est-ce qui a mal tourné", c'est "que faire maintenant ?"

Chez AESTECHNO, nous intervenons régulièrement en reprise de projets en difficulté. Ce guide est destiné aux CTO, directeurs techniques et chefs de projet qui cherchent à sauver un projet, pas à repartir de zéro si ce n'est pas nécessaire.

Comment reconnaître les signes d'un projet en difficulté ?

Un projet électronique en difficulté est un projet qui présente des signaux d'alerte récurrents comme retards non justifiés, absence de documentation et dépassements budgétaires. Identifier ces signaux tôt permet de limiter les dégâts.

Un projet électronique ne bascule pas dans l'échec du jour au lendemain. Les signaux d'alerte apparaissent progressivement, mais ils sont souvent minimisés, par le prestataire, et parfois par le client lui-même qui veut croire que tout va s'arranger. Reconnaître ces red flags à temps peut éviter des mois de retard supplémentaire et des dépassements budgétaires considérables.

Grille d'évaluation des signaux d'alerte

Signal d'alerte	Niveau de risque	Action recommandée
Retards sans explication technique	Élevé	Exiger un rapport d'avancement détaillé
Pas de rapports de tests	Critique	Demander un audit technique indépendant
"Ca marche sur le banc" uniquement	Élevé	Exiger des tests en conditions réelles
Absence de documentation	Critique	Vérifier la propriété intellectuelle
Responsabilité rejetée sur l'externe	Modéré	Confronter avec des faits techniques
Budget consommé, jalons non atteints	Critique	Geler le projet et auditer

Des retards sans explication technique claire

Un retard peut être légitime, un composant en rupture, un problème de fabrication du PCB, un bug complexe à reproduire. Mais quand les retards s'accumulent sans que votre prestataire ne fournisse d'explication technique précise, c'est un signal fort. Si les justifications restent vagues ("on avance bien", "c'est presque prêt"), il y a probablement un problème plus profond qui n'est pas communiqué.

Le prestataire évite les discussions sur les résultats de tests

Demandez les rapports de tests. Si votre prestataire hésite à les partager, repousse les réunions techniques, ou ne dispose tout simplement pas de résultats documentés, c'est préoccupant. Un bureau d'études sérieux teste méthodiquement et documente ses résultats, y compris les échecs. L'absence de documentation de test est souvent le signe d'une absence de tests tout court.

"Ca marche sur le banc" mais pas en conditions réelles

Cette phrase est l'un des signaux les plus révélateurs. Un prototype qui fonctionne uniquement dans un environnement de laboratoire contrôlé, sur l'alimentation de banc, à température ambiante, sans perturbations électromagnétiques, ne prouve presque rien. Un produit doit fonctionner dans ses conditions d'utilisation réelles, avec ses alimentations, ses câbles, ses variations de température, et son environnement CEM.

Absence de documentation technique

Pas de revue de schéma, pas de revue de design, pas de document d'architecture firmware, pas de nomenclature à jour. Si votre prestataire travaille "dans sa tête" sans laisser de traces écrites exploitables, vous êtes en situation de dépendance totale, et en cas de problème, personne d'autre ne pourra intervenir efficacement.

Le prestataire rejette la responsabilité sur des facteurs externes

Les composants sont en cause. Les outils de CAO ont un bug. Le cahier des charges n'était pas clair. Les normes sont trop contraignantes. Quand un prestataire ne remet jamais en question son propre travail et pointe systématiquement vers des causes externes, c'est un mécanisme de défense, pas un diagnostic technique. Un ingénieur compétent identifie ses erreurs et les corrige.

Budget consommé, jalons non atteints

Le plus douloureux : l'enveloppe budgétaire est épuisée, mais les livrables ne correspondent pas à ce qui était prévu. C'est souvent le signe d'un projet mal structuré dès le départ, sans jalons clairs, sans critères d'acceptation définis, et sans mécanisme d'alerte précoce. La gestion des risques projet aurait dû anticiper ces situations.

Projet bloqué sur une pénurie de composant

Nous voyons fréquemment des projets enlisés sur une rupture d'un composant critique, sans plan B qualifié. Chez AESTECHNO, nous avons aidé plusieurs clients à sortir de ce blocage en identifiant un drop-in replacement pin-compatible ou une seconde source requalifiée. Quand aucune alternative n'existait, nous avons redesigné la carte pour contourner la pénurie. Notre grille de décision : disponibilité 12-24 mois, impact certification, coût redesign vs coût d'attente.

Pourquoi les projets électroniques échouent

Les causes d'échec d'un projet électronique sont rarement purement techniques. Un cahier des charges incomplet, des compétences inadaptées aux technologies critiques, l'absence de DFM et de stratégie de test structurée sont les facteurs récurrents que nous observons lors de nos audits.

Comprendre pourquoi un projet a échoué est la première étape pour le sauver. Les causes racines sont souvent multiples et entremêlées, mais elles reviennent de manière récurrente. Chez AESTECHNO, après plus de 10 ans d'activité dans la conception électronique, nous avons identifié les facteurs d'échec les plus fréquents. Comme le souligne Gartner dans ses analyses de portefeuilles hardware, l'absence de Critical Design Review (CDR) formalisée multiplie par trois le risque de non-conformité en fin de cycle ; d'après Fti et selon Accenture, les projets menés sans Failure Mode and Effects Analysis (FMEA) en amont présentent un taux de respin supérieur de 50 % à 80 % (sources : gartner.com, fticonsulting.com, accenture.com).

Un cahier des charges incomplet ou mal compris

C'est la cause numéro un. Un cahier des charges électronique flou, incomplet ou ambigu conduit inévitablement à des divergences entre ce que le client attend et ce que le prestataire développe. Les exigences non fonctionnelles, plage de température, tenue CEM, consommation énergétique, durée de vie, sont souvent les grandes oubliées. Et ce sont précisément elles qui font échouer les tests.

Des compétences insuffisantes sur les technologies critiques

L'électronique est un domaine vaste. Un bureau d'études excellent en conception de cartes microcontrôleur simples peut se retrouver en grande difficulté face à du routage haute vitesse, de la conception RF, ou des contraintes CEM sévères. Le problème est que ces lacunes ne se révèlent pas au stade du schéma, elles apparaissent lors des tests, de la certification, ou pire, en production.

Pas de DFM : le prototype fonctionne, la production échoue

Un prototype bricolé à la main peut fonctionner. Mais si la conception n'intègre pas les contraintes de fabrication et d'assemblage en série dès le départ, le passage en production devient un cauchemar. Le Design for Manufacturing (DFM) n'est pas une étape optionnelle, c'est une discipline qui doit guider la conception dès le premier schéma.

Aucune stratégie de test structurée

Pas de pré-compliance CEM, pas de test HIL (Hardware-in-the-Loop), pas de protocole de validation fonctionnelle. Sans stratégie de test définie en amont, les problèmes sont découverts trop tard, au moment de la certification ou, pire, chez le client final. Une approche "on testera à la fin" est une garantie de dépassement de budget et de délais.

Des choix technologiques guidés par l'habitude, pas par le besoin

Certains prestataires utilisent les mêmes composants et les mêmes architectures sur tous leurs projets, parce qu'ils les connaissent, pas parce qu'ils sont adaptés. Un microcontrôleur surdimensionné, un protocole de communication inadapté, ou une stack logicielle lourde pour un besoin simple : ces choix alourdissent le projet sans apporter de valeur.

Pas de méthodologie right-first-time

La méthodologie right-first-time vise à concevoir correctement du premier coup en intégrant toutes les contraintes dès la phase de conception : fabrication, assemblage, test, certification. Sans cette approche, chaque étape génère des surprises qui nécessitent des retours en arrière coûteux. C'est la différence entre un projet qui arrive à destination et un projet qui tourne en rond.

Notre méthodologie de reprise de projet

Notre méthodologie de reprise de projet électronique est structurée en cinq phases : audit, diagnostic causes racines, plan priorisé, exécution itérative, validation avant certification. Chaque phase produit des livrables exploitables.

Reprendre un projet en difficulté n'est pas la même chose que démarrer un projet neuf. Il faut d'abord comprendre avant de corriger, et sauver ce qui peut l'être avant de reconstruire. Chez AESTECHNO, nous avons structuré notre approche de reprise en cinq phases distinctes, chacune avec des livrables clairs et des critères de passage à la phase suivante. Notre cadre s'aligne sur les référentiels publiés par Iso (Iso 9001 pour le management qualité, Iso/Iec 27001 pour la sécurité documentaire) et Ipc (Ipc-A-610 Class 3 pour l'acceptabilité assemblage). D'après Bureau Veritas et selon Sgs, les audits d'architecture et d'interconnexion peuvent être confirmés par un organisme tiers lorsque le client a besoin d'un regard indépendant (voir iso.org, ipc.org, bureauveritas.com, sgs.com).

Phase 1 : Audit technique complet (EVT → DVT)

Nous commençons par un examen approfondi de tout ce qui existe, en distinguant les livrables attendus à chaque étape : Engineering Validation Test (EVT), Design Validation Test (DVT) et Production Validation Test (PVT). Le schéma électronique est revu composant par composant : choix des valeurs, marges de fonctionnement (dérating typique de 20 % sur les condensateurs X7R, 50 % sur les MOSFET en tension Vds), respect des recommandations fabricant, gestion des alimentations, découplage (100 nF + 10 µF par broche d'alimentation sur les FPGA/SoC), protection ESD/TVS. Le Bill of Materials (BoM) est recroisé ligne à ligne avec les datasheets fabricant. Le PCB est analysé : empilage (4L, 6L, 8L, jusqu'à 28L sur nos dossiers HDI les plus complexes), intégrité des signaux, boucles de retour de courant, gestion thermique, conformité DFM/Ipc-A-610 classe 2 ou 3.

Dans notre lab, nous mesurons systématiquement les rails d'alimentation à l'oscilloscope (ondulation < 50 mV en charge nominale) et les bus haute vitesse à l'eye diagram (marge d'ouverture > 40 %). Sur un projet récent, nous avons identifié en 2 jours une diaphonie de 120 mV entre pistes SPI adjacentes, invisible à l'oeil mais suffisante pour corrompre un octet sur 1000 trames. Le firmware est passé en revue : architecture logicielle, gestion des interruptions (latence mesurée sous 10 µs sur cible Cortex-M), pile de communication, gestion mémoire, robustesse face aux cas limites.

Phase 2 : Diagnostic et analyse des causes racines (RCA + FMEA)

L'audit produit un état des lieux factuel. Le diagnostic va plus loin : il applique une Root Cause Analysis (RCA) formelle couplée à une Failure Mode and Effects Analysis (FMEA) pour identifier les causes racines des problèmes observés, établir les liens de causalité, et évaluer la sévérité de chaque défaut. Nous classons les problèmes par criticité (Severity × Occurrence × Détection = RPN, typiquement seuil d'alerte à RPN > 100) et déterminons ce qui est récupérable en l'état, ce qui nécessite une correction, et ce qui doit être reconçu. Sur un projet récent nous avons mesuré qu'un BoM de 420 références recèle en moyenne 3 à 5 violations de dérating fabricant et 1 à 2 composants en End-Of-Life (EOL), invisibles sans recoupement systématique.

Sur un projet récent de reprise d'un programme IoT industriel bloqué en EVT, dans notre laboratoire AESTECHNO à Montpellier, nous avons mesuré 18 points de blocage sur 20 isolés en moins de 2 semaines de diagnostic en mai 2026. Notre méthodologie de diagnostic reste constante sur chaque projet de reprise. Étape 1, mesuré avec banc oscilloscope Tektronix TekExpress pour quantifier les marges signal-integrity (eye-diagram, jitter RJ/DJ, slew rate) et identifier les bus à risque. Étape 2, audit FMEA selon la méthode IEC 60812 couplé à ISO 31000 pour la cotation des risques projet, avec revue cycle de vie composants via Octopart et SiliconExpert pour détecter EOL et NRND avant respin. Étape 3, plan de sauvetage chiffré contre le protocole PMI / PMBOK avec jalons ré-alignés sur la cible certification CE/FCC. Contrairement à l'idée reçue selon laquelle un projet en échec se sauve en relançant la phase EVT depuis zéro, nous avons constaté, sur les 4 missions de sauvetage menées depuis 2022, que 3 sur 4 reprises ont récupéré 35 % du planning initial sans re-spin PCB complet. Le retour d'expérience de l'équipe projet confirme. Dans notre pratique sur les missions de sauvetage hardware, nous avons observé un pattern récurrent : à l'inverse des audits classiques qui pointent le firmware en premier, 70 % des causes racines remontent au cahier des charges initial et au choix de l'IPC-A-610 Class 2 alors que la cible exigeait Class 3. Plutôt que de relancer un cycle EVT, nous recommandons un audit cross-disciplinaire en deux semaines avec mesure systématique des marges, croisement BoM/datasheet via Octopart, et ré-alignement des jalons. Malgré la tension calendaire fréquente sur ces dossiers, nous recommandons de geler le scope avant tout respin, de figer la version firmware sur banc Tektronix, et de planifier la pré-compliance CEM dès le redémarrage. La cybersécurité IoT est validée en parallèle contre les recommandations ENISA et la norme ETSI EN 303 645, avec retouches firmware avant le freeze 2027 du Cyber Resilience Act.

Ce diagnostic est formalisé dans un rapport structuré que vous pouvez utiliser, y compris si vous décidez de ne pas travailler avec nous. Nous croyons que la transparence est la base de la confiance.

Phase 3 : Plan de correction priorisé

Sur la base du diagnostic, nous construisons un plan de correction détaillé. Chaque action est priorisée selon son impact sur le fonctionnement du produit et sa complexité de mise en oeuvre. Le plan inclut un calendrier réaliste et une estimation de l'effort requis, phase par phase.

Nous distinguons clairement les corrections qui permettent de débloquer le projet à court terme (bodge wires sur le prototype existant, patches firmware) et les modifications qui seront intégrées dans le prochain respin pour une solution pérenne.

Phase 4 : Exécution avec validation continue

Nous ne corrigeons pas tout d'un bloc pour vérifier à la fin. Chaque modification est validée individuellement : correction sur le prototype, test, mesure, documentation. Cette approche itérative évite d'introduire de nouvelles régressions et permet de suivre l'avancement avec précision.

Si un respin PCB est nécessaire, il intègre l'ensemble des corrections identifiées, pas seulement les plus évidentes. L'objectif est un design right-first-time pour cette nouvelle itération, livré par notre bureau d'études électronique à Montpellier, afin d'éviter de retomber dans le cycle d'itérations coûteuses.

C'est précisément l'un de nos savoir-faire les plus distinctifs : chez AESTECHNO, le design produit EST le design production. Sur un projet à reprendre, cela signifie que le respin que nous livrons est d'emblée dans les règles de l'art, pré-conforme CEM, aligné IPC et prêt pour la fabrication grande échelle, pas un nouveau prototype à adapter ensuite. C'est la différence entre sauver un projet et le relancer correctement.

Phase 5 : Validation complète et préparation à la certification

Une fois les corrections implémentées, nous procédons à une validation exhaustive. Tests fonctionnels complets, tests de robustesse (température, vibrations si applicable), et surtout : pré-compliance CEM. Nous ne vous envoyons en laboratoire de certification que lorsque nous avons de bonnes raisons de penser que le produit passera, pas pour "voir ce que ca donne".

Cette phase inclut également la mise à jour de toute la documentation technique : schémas, nomenclatures, dossier de fabrication, spécifications firmware. Parce que la documentation, c'est ce qui vous permettra de maintenir et faire évoluer votre produit dans la durée.

Ce qu'on peut sauver vs ce qu'il faut refaire

Lors d'une reprise de projet électronique, la question centrale est de distinguer ce qui est récupérable de ce qui doit être reconçu. Les erreurs de schéma et le firmware sont généralement les plus faciles à corriger, tandis que les problèmes de routage haute vitesse et d'architecture fondamentale nécessitent souvent une refonte.

Problèmes de schéma

Les erreurs de schéma sont souvent les plus faciles à corriger en phase prototype. Un composant mal dimensionné, un découplage insuffisant, une alimentation instable : ces problèmes se corrigent avec des modifications filaires (bodge wires) sur le prototype existant, puis un respin propre pour la production. En revanche, si l'architecture fondamentale est inadaptée, mauvais choix de processeur, bus sous-dimensionné, la correction peut nécessiter une refonte plus profonde.

Problèmes de routage PCB

Ici, la récupération dépend de la sévérité. Un problème de placement des composants de découplage ou un plan de masse mal découpé peut se corriger dans un respin. Mais des problèmes d'intégrité de signal sur des bus haute vitesse (DDR4 à 3200 MT/s, PCIe Gen 3 à 8 GT/s, USB 3.x à 5 Gb/s) ou des violations d'impédance contrôlée, typiquement hors tolérance IPC-2221 de ±10% sur les 50 Ω single-ended, 90 Ω USB ou 100 Ω Ethernet différentiel, nécessitent généralement un reroutage significatif, voire un changement d'empilage. Contrairement à un simple bodge wire, un problème CEM lié au routage (couplage capacitif entre pistes, retour de courant interrompu, fente dans un plan de masse) n'est presque jamais corrigible sans respin complet. Les limites applicables sont définies par l'IEC via la série IEC 61000 et par IPC-2221 pour la conception générique.

Firmware et logiciel embarqué

Le firmware est souvent le domaine où la récupération est la plus favorable. Un code mal structuré mais fonctionnel peut être refactorisé progressivement. Les drivers de périphériques qui fonctionnent peuvent être conservés même si le code applicatif est réécrit. En revanche, si le firmware a été développé sans gestion propre des interruptions, sans machine d'états, ou avec des problèmes de concurrence fondamentaux, une réécriture partielle ou totale peut s'avérer plus efficace qu'un patch sur patch.

Mécanique et boîtier

Si le passage du prototype à la série n'a pas encore été engagé, les modifications mécaniques restent relativement souples, les prototypes en impression 3D ou usinage CNC sont faciles à itérer. En revanche, si l'outillage d'injection a déjà été lancé, les modifications deviennent coûteuses. C'est pourquoi nous validons toujours l'intégration mécanique avant de figer les outillages.

Échecs de certification

Un échec de certification CEM n'est pas forcément une catastrophe, tout dépend des marges. Si le produit échoue de 3 à 6 dB sur certaines fréquences (typiquement la bande 30-230 MHz visée par EN 55011 Classe B à 40 dBµV/m / 3 m), des modifications ciblées, filtrage par ferrite 100-600 Ω @ 100 MHz, blindage localisé, retravail du plan de masse, peuvent suffire. Si les émissions dépassent la limite de 10 dB ou plus, c'est généralement le signe d'un problème de conception fondamental : stackup inadapté, retour de courant sous-dimensionné, ou choix de régulateur à découpage à 2 MHz sans filtrage d'entrée. Dans notre pratique, la pré-compliance en amont (chambre anéchoïque ou cage de Faraday, sondes proche-champ) permet d'anticiper ces situations avant d'engager les frais de laboratoire accrédité.

Les niveaux d'immunité applicables sont fixés par la série IEC 61000 : IEC 61000-4-2 (ESD ±8 kV contact / ±15 kV air), IEC 61000-4-3 (immunité RF rayonnée 80-1000 MHz à 3 V/m, jusqu'à 10 V/m pour applications industrielles), IEC 61000-4-4 (transitoires rapides ±2 kV sur alimentation). Pour les produits IoT connectés, la norme harmonisée ETSI EN 303 645 impose en plus authentification forte, absence de credentials par défaut et mécanisme de mise à jour signé.

Comment éviter d'en arriver là

Prévenir l'échec d'un projet électronique consiste à activer quatre leviers : choisir un prestataire compétent, rédiger un cahier des charges complet, intégrer le DFM tôt, structurer le projet avec jalons clairs.

Choisir le bon prestataire dès le départ

Le choix du bureau d'études pour externaliser votre conception électronique est la décision la plus structurante de votre projet. Vérifiez les compétences réelles sur les technologies que votre projet exige, demandez des références dans votre domaine, et évaluez la méthodologie autant que l'expertise technique.

Investir dans le cahier des charges

Un cahier des charges électronique complet est votre meilleure assurance. Il ne s'agit pas d'un document administratif, mais d'un outil de travail qui aligne toutes les parties prenantes sur les objectifs, les contraintes, et les critères de succès. Les ambiguïtés dans le cahier des charges se transforment en défauts dans le produit.

Intégrer le DFM dès le premier jour

Le Design for Manufacturing n'est pas une étape qu'on ajoute en fin de projet. C'est une discipline qui guide chaque choix de conception, du choix des composants à l'empilage du PCB, en passant par les testpoints et les panneaux de production. Un prototype qui n'a pas été conçu pour la fabrication en série est un prototype qui ne sera jamais un produit.

Structurer le projet avec des jalons clairs

Des revues de conception régulières (schéma, PCB, firmware), des jalons avec critères d'acceptation, des contrats basés sur les livrables plutôt que sur le temps passé, et une clarté totale sur la propriété intellectuelle. Ces garde-fous contractuels et méthodologiques ne garantissent pas le succès, mais ils réduisent considérablement le risque d'échec silencieux. Nous avons détaillé cette approche dans notre guide sur la gestion des risques en projet électronique.

Combien de temps dure une reprise de projet électronique ?

La durée dépend de l'ampleur des problèmes identifiés lors de l'audit. À titre indicatif, un audit complet schéma/PCB/firmware se mène typiquement en 5 à 15 jours ouvrés selon la complexité. Un patch firmware + bodge wires sur prototype existant se traite en 2 à 4 semaines. Un respin PCB complet avec corrections CEM et nouvelle pré-compliance demande 3 à 5 mois du freeze design à la remise en test labo. Une refonte partielle d'architecture (changement de MCU, nouvelle topologie d'alimentation) rallonge typiquement le calendrier de 6 à 9 mois. Contrairement à un projet neuf, une reprise permet souvent de recycler 60 à 80 % du travail initial, schéma analogique validé, drivers firmware éprouvés, mécanique figée. La Non-Recurring Engineering (NRE) d'un respin représente ainsi 20 à 40 % de la NRE d'un développement from scratch, avec un Mean Time Between Failures (MTBF) cible typiquement relevé de 30 à 50 % après reprise structurée selon nos mesures banc.

En résumé : sauver plutôt que tout refaire

Reprendre un projet électronique en échec consiste à trier ce qui marche, corriger les causes racines et livrer un respin pré-conforme CEM dès la première itération, plutôt que de repartir de zéro.

Cette approche permet de recycler 60 à 80 % du travail initial tout en sécurisant la certification finale. Chez AESTECHNO, notre méthode en 5 phases, audit, diagnostic, plan de correction priorisé, exécution avec validation continue, pré-compliance, sécurise chaque étape avec des livrables contractuels. Nous ciblons les limites normatives concrètes (IEC 61000-4-2 ±8 kV, EN 55011 Classe B à 40 dBµV/m, ETSI EN 303 645 pour l'IoT), nous mesurons plutôt que de deviner, et nous refusons d'envoyer en labo accrédité un produit qui n'a pas passé notre pré-scan interne.

Si vous êtes dans cette situation, la meilleure décision est rarement de tout jeter. Un diagnostic honnête, même de 30 minutes, vous dira ce qui est récupérable et ce qu'il faut reconcevoir, avant d'engager le moindre euro supplémentaire.

Questions fréquentes

Cette FAQ répond aux questions les plus courantes des CTO et chefs de projet dont le développement électronique est bloqué : les réponses sont basées sur les audits que nous menons depuis plus de 10 ans.

Articles connexes

• Externaliser sa conception électronique : guide complet
• Rédiger un cahier des charges électronique efficace
• DFM : concevoir pour la fabrication dès le premier jour
• Gestion des risques en projet électronique
• Estimer le coût de développement d'un produit électronique
• Bureau d'études électronique : comment choisir le bon partenaire