Le métier suit un cycle très encadré. Chaque ligne de code découle d'une exigence de bas niveau, elle-même reliée à une exigence de plus haut niveau, et chaque exigence est couverte par des tests. La norme appliquée fixe la rigueur demandée selon la gravité d'une défaillance : DAL A à E en DO-178C, ASIL A à D en ISO 26262, SIL 1 à 4 en IEC 61508 et en EN 50128, qu'EN 50716 remplace depuis fin 2023. Plus le niveau monte, plus la couverture structurelle exigée est fine, jusqu'à la MC/DC.
Citer une norme sur un CV veut souvent dire que le projet y était soumis, sans que la personne ait écrit une exigence ou justifié un trou de couverture. L'expérience se reconnaît quand le candidat explique pourquoi un test n'atteint pas une condition, ce que la norme appelle code mort, ou ce qu'il faut pour utiliser un outil dont personne ne relit la sortie. Les principes sont proches d'une norme à l'autre, et un ingénieur rodé sur l'une s'adapte vite à une autre.
Une exigence floue à réécrire ou une fonction de vingt lignes dont il faut construire les cas MC/DC suffit pour voir le niveau. Le PDF propose un cas de 20 minutes sur un trou de couverture découvert deux semaines avant un audit.
Normes et outils du logiciel critique
DO-178C et ses suppléments
La norme du logiciel embarqué aéroporté, publiée en Europe sous le nom ED-12C. Elle classe le logiciel du niveau A, où une défaillance serait catastrophique, au niveau E, et liste des objectifs à atteindre plutôt que des méthodes. Ses suppléments traitent de la qualification des outils (DO-330), du développement par modèles (DO-331), de l'orienté objet (DO-332) et des méthodes formelles (DO-333).
ISO 26262
La norme de sécurité fonctionnelle des véhicules routiers. Sa partie 6 couvre le logiciel : exigences, architecture, unités, tests, avec des méthodes recommandées selon l'ASIL, de A à D. Le logiciel reçoit son niveau des analyses menées en amont sur le système, avec des décompositions possibles.
IEC 61508, EN 50128 et EN 50716
IEC 61508 est la norme générique de sécurité fonctionnelle des systèmes électroniques programmables, dont dérivent plusieurs normes métier. EN 50128 encadrait le logiciel ferroviaire de signalisation. EN 50716, publiée en 2023, la remplace et couvre aussi le logiciel embarqué du matériel roulant. Ces normes reposent sur des niveaux SIL et des tableaux de techniques recommandées.
Exigences et traçabilité
IBM DOORS, Polarion, Jama ou Reqtify portent les exigences et leurs liens vers le code et les tests. L'auditeur demande une traçabilité dans les deux sens : toute exigence est codée et testée, tout code découle d'une exigence.
Tests unitaires et couverture
VectorCAST, LDRA, Cantata ou RapiCover mesurent la couverture des instructions, des décisions et la MC/DC, sur hôte ou sur cible. La MC/DC demande de montrer que chaque condition d'une décision change à elle seule le résultat. Elle est exigée au niveau A de DO-178C et fortement recommandée en ASIL D.
Analyse statique et preuve
Polyspace (Bug Finder et Code Prover), Astrée ou Frama-C cherchent les erreurs d'exécution : débordements, divisions par zéro, accès hors tableau. Les outils par interprétation abstraite prouvent leur absence sur tout le code, ce qu'aucun test ne fait. Les règles MISRA C se contrôlent avec le même type d'outil.
Temps d'exécution au pire cas (WCET)
Le pire temps d'exécution doit être borné et justifié. aiT d'AbsInt le calcule par analyse statique, RapiTime le mesure sur cible. Sur processeur multicœur, la démonstration se complique, car les cœurs partagent bus et mémoire.
Qualification d'outils
Un outil dont la sortie n'est pas vérifiée doit être qualifié : générateur de code, outil qui remplace une revue, outil de couverture. DO-330 fixe des niveaux TQL, ISO 26262 des niveaux TCL. Les éditeurs vendent souvent un kit de qualification, que le projet adapte encore à son usage réel.
Les intitulés varient : ingénieur logiciel embarqué critique, ingénieur logiciel safety, développeur C embarqué DO-178, ingénieur V&V logiciel, ingénieur qualité logicielle. Les postes de développement écrivent exigences de bas niveau, code et tests unitaires. Les postes de vérification relisent, testent et mesurent la couverture, avec une indépendance exigée aux niveaux les plus élevés. Les postes de qualité suivent l'application des plans et préparent les audits. Les langages restent surtout le C et l'Ada, parfois un sous-ensemble du C++ ou du code généré par SCADE ou Simulink. Aucune certification individuelle n'est obligatoire. Des formations aux normes existent, mais l'expérience se vérifie sur des exigences écrites, des tests et des écarts traités.
Les points à contrôler pendant l'entretien
- Exigences et traçabilité
- Couverture structurelle et MC/DC
- Tests basés sur les exigences
- Analyse statique et MISRA C
- Robustesse, temps réel et WCET
- Outils qualifiés et dossier de certification
Questions d'entretien sur la MC/DC, les exigences et les outils
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Soit la décision if (a && (b || c)). Combien de cas de test faut-il au minimum pour la MC/DC, et lesquels ?
Une bonne réponseQuatre, soit le nombre de conditions plus un. Il construit pour chaque condition une paire de cas où elle seule change et fait changer le résultat. Avec (a, b, c) : VVF et FVF pour a, VVF et VFF pour b, VFV et VFF pour c. Les cas communs se partagent, d'où quatre vecteurs : VVF, FVF, VFF, VFV. Il précise que l'évaluation en court-circuit du C compte, et que la variante de MC/DC retenue (cause unique ou masquage) doit être écrite dans le plan de vérification.
Signal d'alerteHuit cas « pour tout tester », ou une confusion entre couverture des décisions et MC/DC.
Question 2 · confirmé
Les tests basés sur les exigences laissent 3 % du code non couvert. Comment traitez-vous chaque trou ?
Une bonne réponseIl analyse chaque cas avant d'écrire le moindre test. Exigence manquante ou incomplète : on corrige l'exigence, puis on ajoute le test. Test insuffisant : on complète le test. Code mort, sans exigence : on le supprime. Code désactivé, prévu pour une configuration non utilisée : on le justifie et on montre qu'il ne peut pas s'exécuter. Code défensif inatteignable : justification écrite et revue. Il refuse d'écrire un test structurel sans exigence juste pour atteindre 100 %.
Signal d'alerte« J'écris des tests qui passent par les lignes manquantes », sans lien avec une exigence.
Question 3 · junior à confirmé
Comment reconnaissez-vous une exigence logicielle mal écrite ? Donnez un exemple que vous corrigez.
Une bonne réponseUne bonne exigence est vérifiable, sans ambiguïté, unique et reliée à son exigence parente. Il repère les mots vagues (« rapidement », « si possible », « correctement »), les exigences qui en contiennent deux, celles sans valeur limite ni comportement en cas d'erreur. Par exemple, « le logiciel surveille la température » devient « si la température mesurée dépasse 105 °C pendant plus de 200 ms, le logiciel active l'alarme au cycle suivant ».
Signal d'alerteUne exigence qui décrit le code (« la fonction appelle X ») sans voir qu'il s'agit d'une description de conception.
Question 4 · confirmé
Vous utilisez un générateur de code dont personne ne relit la sortie. Que faut-il pour que ce soit acceptable ?
Une bonne réponseL'outil doit être qualifié, car une erreur de sa part passerait inaperçue. En DO-178C, le niveau de qualification (TQL) dépend du critère de l'outil et du niveau du logiciel, et DO-330 décrit le dossier. En ISO 26262, on détermine le niveau de confiance (TCL) à partir de l'impact de l'outil et de la probabilité de détecter son erreur. L'autre voie consiste à vérifier la sortie, par revue et tests sur le code généré. Un kit de qualification fourni par l'éditeur doit être complété avec l'usage réel du projet.
Signal d'alerte« L'outil est connu, tout le monde l'utilise. »
Question 5 · confirmé à senior
Polyspace Code Prover signale 40 vérifications orange sur un module. Comment les traitez-vous ?
Une bonne réponseUne vérification orange signifie que l'outil ne prouve ni l'erreur ni son absence. Il les trie par type et commence par celles qui ont une cause commune, souvent des entrées dont l'outil ne connaît pas les bornes. Il ajoute des contraintes sur les entrées quand l'information existe dans les exigences, relance, puis justifie les restantes par une analyse écrite et revue. Il corrige le code quand l'alarme révèle un vrai risque, par exemple un débordement possible lors d'une conversion.
Signal d'alerteMasquer les alarmes en bloc, ou les classer comme faux positifs sans les lire.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ce que les recruteurs demandent sur ce poste
Un ingénieur habitué à DO-178C peut-il travailler sous ISO 26262 ou EN 50716 ?
Oui, dans la plupart des cas. Les normes partagent les mêmes principes : niveaux de criticité, exigences tracées, couverture, indépendance de la vérification, qualification des outils. Le vocabulaire et les documents changent, comme le PSAC d'un côté et le plan de sécurité de l'autre. Prévoyez quelques semaines d'adaptation et une formation courte à la norme visée. Vérifiez surtout que la personne a pratiqué le niveau de criticité de votre projet.
Faut-il distinguer développement et vérification dans l'offre ?
Oui, car les normes demandent souvent que la vérification soit faite par une autre personne que l'auteur. Un développeur écrit exigences de bas niveau, code et parfois tests unitaires. Un vérificateur relit, écrit les tests basés sur les exigences et analyse la couverture. Les deux profils se recoupent, mais leurs journées diffèrent. Une offre floue attire des candidats qui découvrent le rôle réel à l'entretien.
Comment organiser un test technique pour un poste de logiciel critique ?
Préparez trois exercices courts plutôt qu'un long sujet. Une exigence ambiguë à réécrire, une décision à trois conditions dont il faut construire les cas MC/DC, une fonction C de vingt lignes avec une conversion non protégée et une gestion d'erreur absente. Faites-les traiter pendant l'entretien, en demandant à la personne de commenter. Quarante-cinq minutes suffisent pour situer un développeur ou un vérificateur.
Que vaut une formation DO-178C ou ISO 26262 sur un CV ?
Elle montre que la personne connaît la structure de la norme et son vocabulaire. Elle ne dit pas si elle a déjà écrit une exigence vérifiable, traité un trou de couverture ou préparé un audit. Demandez un exemple précis : une déviation MISRA rédigée, un outil qualifié, une anomalie traitée après livraison. Sans exemple, considérez le profil comme junior sur la partie sûreté, même avec plusieurs années de C embarqué.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
