Modèle en V en développement logiciel : phases, niveaux de test et quand l’utiliser en 2026

Marcus Chen Ingénieur principal, Backend & Cloud, YuSMP Group · Livraison de programmes pilotés par le plan et hybrides pour des clients réglementés aux États-Unis et en Europe

Le modèle en V en développement logiciel est une façon séquentielle de construire un logiciel dans laquelle chaque phase de développement a une phase de test correspondante, et où le test de chaque phase est planifié en même temps que la phase elle-même. En France, on parle le plus souvent de cycle en V. Le modèle se dessine comme la lettre V : la conception descend la branche gauche, le codage est à la pointe et les tests remontent la branche droite. Cela ressemble à une idée des années 1990, et c’en est une. Pourtant, en 2026, il soutient toujours les audits dans l’automobile, les dispositifs médicaux, l’avionique et l’informatique publique, parce que les autorités de ces domaines exigent la preuve que chaque exigence a été testée.

Cette preuve explique pourquoi le V perdure. Une équipe moderne livre peut-être en sprints de deux semaines, mais lorsqu’un évaluateur ISO 26262 ou un examinateur de la FDA arrive, il demande une chaîne reliant chaque exigence à sa conception, son code et son résultat de test. Cette chaîne, c’est précisément ce que produit le V. C’est aussi pourquoi la plupart des équipes qui assurent du développement logiciel d’entreprise pour les secteurs réglementés structurent encore leurs preuves de test autour du V, même quand le travail quotidien se fait en sprints.

Ce guide explique le modèle en V du développement logiciel à partir des fondamentaux : le rôle de chaque branche du V, un schéma texte réutilisable, un exemple concret de traçabilité des exigences, une liste honnête des avantages et inconvénients, une comparaison avec la cascade, l’Agile et le modèle en W, et un regard pratique sur les cas où le V est le bon choix et ceux où il ne l’est pas.

Qu’est-ce que le modèle en V en développement logiciel ?

Le modèle en V en développement logiciel est un cycle de vie piloté par le plan dans lequel chaque phase de développement de la branche gauche du V est reliée à un niveau de test de la branche droite qui la contrôlera plus tard. La branche gauche correspond à la vérification : construisons-nous le produit correctement ? La branche droite correspond à la validation : construisons-nous le bon produit ? Le codage se trouve à la pointe, là où les deux branches se rejoignent.

Le modèle est généralement présenté comme une extension du modèle en cascade. La cascade enchaîne les phases et place les tests vers la fin. Le V conserve le même ordre pour la construction, mais remonte la ligne après le codage, de sorte que chaque niveau de test fait face à la phase de conception qu’il valide. Kevin Forsberg et Harold Mooz ont popularisé la forme en V pour l’ingénierie système dans un article de 1991. Depuis, l’industrie des dispositifs médicaux l’a adoptée, la Federal Highway Administration américaine l’a utilisée dans ses guides d’ingénierie système, et l’Allemagne l’a formalisée dans son standard fédéral V-Modell XT pour les projets informatiques du secteur public.

Pour situer le V parmi les autres approches : il appartient à la famille pilotée par le plan du cycle de vie du développement logiciel, à côté de la cascade, et à l’opposé de la famille itérative qui comprend Scrum et Kanban. Notre panorama des autres méthodologies de développement logiciel les compare toutes.

Vérification vs validation dans le modèle en V

La vérification et la validation répondent à deux questions différentes, et le modèle en V place chacune sur sa propre branche. Le tableau ci-dessous montre comment la distinction fonctionne en pratique.

Schéma du modèle en V : comment les deux branches se répondent

Un schéma du modèle en V montre les phases de développement qui descendent la branche gauche, le codage en bas et les niveaux de test qui remontent la branche droite, avec un lien horizontal entre chaque paire. Ce lien est l’élément clé. Il signifie que le plan de test de la phase de droite est rédigé pendant que la phase de gauche se déroule, et non une fois le code écrit.

Lisez le schéma en haut à gauche, descendez jusqu’à la pointe, puis remontez à droite. Les phases 1 à 4 resserrent le périmètre, des besoins métier jusqu’aux modules individuels. La phase 5 transforme les conceptions détaillées en code. Les phases 6 à 9 élargissent de nouveau le périmètre, de l’unité isolée jusqu’au système complet entre les mains du client. Chaque paire horizontale partage un même niveau d’abstraction, si bien que le test contrôle toujours le travail réalisé au même niveau.

La même correspondance sous forme de tableau de référence, avec l’artefact produit par chaque phase et le responsable habituel de la validation :

Les phases de vérification (branche gauche du V)

Les phases de vérification de la branche gauche du V transforment un besoin métier en une conception assez détaillée pour être codée, et chacune rédige aussi le plan de test de sa partenaire de droite. La vérification y est surtout statique : les documents sont relus, inspectés et validés avant que le travail ne descende d’un niveau.

Analyse des exigences métier (+ plan de recette)

L’analyse des exigences métier recueille ce dont le client et les utilisateurs ont besoin, dans leurs propres termes. Les analystes mènent des ateliers et des entretiens, puis rédigent une spécification avec des exigences fonctionnelles et non fonctionnelles, chacune dotée d’un identifiant unique. En parallèle, l’équipe prépare le plan de recette : pour chaque exigence, comment le client confirmera-t-il plus tard qu’elle fonctionne ? Écrire ce critère d’acceptation dès maintenant met en évidence les exigences floues du type « le système doit être rapide ».

Conception système (+ plan de tests système)

La conception système traduit les exigences métier en exigences système et en une description du système complet : frontières matériel et logiciel, interfaces externes, flux de données et objectifs de performance. Dans les projets automobiles ou médicaux, c’est ici que les exigences logicielles et matérielles se séparent. Le plan de tests système est rédigé en même temps et définit les scénarios de bout en bout, les environnements et les données nécessaires pour tester le système intégré par rapport à ces exigences.

Conception architecturale / HLD (+ plan de tests d’intégration)

La conception architecturale, ou conception de haut niveau (HLD), découpe le système en composants et définit leur communication : API, formats de messages, bases de données, services tiers et gestion des erreurs entre eux. Le plan de tests d’intégration est créé en parallèle et cible précisément ces jonctions. Il précise quelles interfaces sont testées, dans quel ordre les composants sont assemblés et quels bouchons ou simulateurs remplacent les éléments pas encore construits.

Conception détaillée / LLD (+ plan de tests unitaires)

La conception détaillée, ou conception de bas niveau (LLD), décrit la logique interne de chaque composant : classes, fonctions, algorithmes, structures de données et conditions limites. C’est la dernière étape avant le code. Le plan de tests unitaires est rédigé ici et liste, pour chaque module, les entrées, cas limites et sorties attendues qu’un test unitaire doit couvrir. Dans les projets critiques pour la sécurité, c’est aussi là que sont fixés les objectifs de couverture structurelle, comme la couverture d’instructions ou MC/DC.

Codage : la pointe du V

Le codage est le point du V où la conception devient logiciel et où la branche droite commence. Les développeurs implémentent chaque module selon sa conception détaillée, en suivant des normes de codage (MISRA C dans l’automobile, par exemple) et en passant revue de code et analyse statique avant les tests unitaires. Comme le plan de tests unitaires existe déjà, les développeurs savent avant d’écrire une ligne quel comportement sera vérifié.

Les phases de validation (branche droite du V)

Les phases de validation de la branche droite du V exécutent les plans de test rédigés plus tôt, de la plus petite unité de code jusqu’au système complet dans l’environnement du client. Chaque niveau teste par rapport à la spécification de sa phase partenaire, et pas seulement par rapport au code. C’est ce qui permet de remonter facilement d’un test en échec à sa cause.

Tests unitaires

Les tests unitaires vérifient chaque module isolément par rapport à sa conception détaillée. Les développeurs ou des testeurs dédiés exécutent le plan de tests unitaires, généralement via un framework automatisé, les dépendances étant remplacées par des mocks ou des bouchons. Un échec unitaire pointe directement vers une erreur de codage ou un défaut de conception détaillée, l’endroit le moins coûteux pour corriger sur la branche droite du V.

Tests d’intégration

Les tests d’intégration vérifient que les modules fonctionnent ensemble comme le prévoit l’architecture. Les équipes assemblent les composants pas à pas, de manière descendante, ascendante ou mixte, et sollicitent les interfaces définies dans la HLD : formats de données, synchronisation, propagation des erreurs et transactions. Les défauts typiques sont des hypothèses divergentes entre équipes, sur les unités de mesure, la gestion des valeurs nulles ou les relances.

Tests système

Les tests système évaluent le système complet et intégré par rapport aux exigences système. Ils couvrent le comportement fonctionnel et les qualités non fonctionnelles : performance, sécurité, fiabilité, ergonomie et, en embarqué, le comportement sur le matériel cible ou sur un banc hardware-in-the-loop. Une équipe QA indépendante les mène généralement dans un environnement aussi proche que possible de la production.

Tests de recette (UAT)

Les tests de recette confirment que le système répond aux exigences métier et qu’il est prêt pour un usage réel. Clients ou utilisateurs finaux exécutent le plan de recette rédigé au tout début du projet, souvent sous forme de tests d’acceptation utilisateur (UAT), complétés par les étapes contractuelles ou réglementaires. Un succès ici referme le V : l’exigence recueillie en phase 1 a démontré son fonctionnement en phase 9.

Comment fonctionne la traçabilité dans le modèle en V ? Un exemple concret

Dans le modèle en V, la traçabilité signifie que chaque exigence peut être suivie en descendant la branche gauche jusqu’au code qui l’implémente, puis en remontant la branche droite jusqu’aux tests qui la prouvent, et inversement. L’outil pour cela est la matrice de traçabilité des exigences (RTM). Automotive SPICE 4.0, publié par le VDA QMC en novembre 2023, exige explicitement une traçabilité bidirectionnelle : des exigences vers les tests et des tests vers les exigences, afin qu’aucun test ne soit orphelin et qu’aucune exigence ne reste non testée.

Voici une exigence suivie à travers tout le V. Prenons un terminal de paiement dont l’exigence métier est REQ-017 : « L’autorisation de paiement doit se bloquer après trois saisies de code PIN erronées. »

1. Exigence métier (phase 1). REQ-017 est rédigée et validée. Son critère d’acceptation : « Après trois PIN erronés avec une vraie carte, le terminal refuse toute nouvelle tentative et affiche le message de blocage. »
2. Exigence système (phase 2). SYS-042 précise que le blocage doit survivre à un redémarrage du terminal et être consigné dans la piste d’audit en moins d’une seconde.
3. Architecture (phase 3). ARC-09 confie le compteur au service d’autorisation et l’état de blocage au composant de stockage sécurisé, avec une interface définie entre les deux.
4. Conception détaillée (phase 4). MOD-AUTH-3 définit la logique du compteur, y compris sa remise à zéro après un PIN correct et le comportement limite à exactement trois tentatives.
5. Code (phase 5). Le module PinAttemptCounter implémente MOD-AUTH-3.
6. Tests (phases 6 à 9). UT-311 vérifie le compteur à 2, 3 et 4 tentatives ; IT-58 vérifie que le blocage atteint le stockage sécurisé ; ST-120 redémarre le terminal pendant le blocage ; AT-17 rejoue le scénario client avec une vraie carte.

L’extrait correspondant de la RTM se présente ainsi :

Deux éléments rendent la RTM utile plutôt que bureaucratique. D’abord, une ligne en échec indique immédiatement quelle exigence est menacée et quel élément de conception vérifier : REQ-020 a échoué au niveau système, donc la correction commence par SYS-050 et non par une recherche au hasard dans le code. Ensuite, une demande de changement devient une analyse d’impact. Si le métier modifie REQ-017 en « blocage après cinq tentatives », la matrice liste chaque élément de conception et chaque test à modifier des deux côtés du V.

Principes fondamentaux du modèle en V

Le modèle en V repose sur quelques principes qui le distinguent d’un simple processus séquentiel. Tous se résument à une idée : réfléchir à la manière de tester quelque chose au moment même où l’on décide de ce qu’il doit être.

• Planification des tests en parallèle du développement. Chaque phase de gauche livre son plan de test associé, si bien que les tests commencent dès le premier jour et non après le codage.
• Prévenir les défauts plutôt que les détecter. Écrire des tests à partir d’une spécification révèle les ambiguïtés et les lacunes avant qu’elles ne deviennent du code. Les coûts augmentent fortement à mesure qu’un défaut est découvert tard, la prévention est donc rentable.
• Des exigences claires et testables. Une exigence sans critère d’acceptation n’est pas terminée. Le V impose cette discipline.
• Jalons de phase et validation formelle. Chaque phase se termine par une revue et une approbation avant la suivante, ce qui crée des points d’audit naturels.
• Test statique à gauche, test dynamique à droite. Revues, inspections et analyse statique vérifient documents et code ; les tests par exécution valident le comportement.
• Correspondance un à un entre phases et tests. Chaque niveau de développement a exactement un niveau de test qui le contrôle, au même niveau d’abstraction.

Avantages et inconvénients du modèle en V

Le modèle en V échange de la flexibilité contre du contrôle. Il produit d’excellentes preuves et une conception précoce des tests, mais peine quand les exigences bougent. Les deux listes ci-dessous méritent d’être lues avant de le choisir.

Avantages

• Conception précoce des tests. Les plans de test existent avant le code, si bien que les testeurs trouvent les défauts de spécification tant qu’ils sont encore peu coûteux à corriger.
• Preuves prêtes pour l’audit. Spécifications, comptes rendus de revue, plans et résultats de test ainsi que la RTM sont des sous-produits naturels, exactement ce que demandent les évaluateurs.
• Livrables clairs par phase. Chacun sait ce que chaque phase doit produire et qui l’approuve.
• Jalons et étapes prévisibles. L’avancement est facile à rapporter et à lier à des paiements ou à des étapes de certification.
• Moins de surprises tardives. Les défauts trouvés à chaque niveau de test renvoient à une phase de conception précise, ce qui raccourcit l’analyse des causes.
• Adapté au périmètre fixe et aux contrats. Les contrats au forfait et réglementés s’alignent naturellement sur les phases figées du V.

Inconvénients

• Rigide face aux changements d’exigences. Un changement en haut du V se répercute sur la conception, le code et quatre niveaux de plans de test.
• Le logiciel fonctionnel arrive tard. Les parties prenantes ne voient un système qui tourne qu’après le codage et les premiers tests.
• Reprises coûteuses. Une erreur d’exigence découverte en recette oblige à revoir chaque phase située en dessous.
• Charge documentaire élevée. Spécifications, plans et matrices demandent un vrai effort de rédaction et de mise à jour.
• Boucle de retour client faible. Les utilisateurs ne valident le produit qu’à la fin, sauf si l’équipe ajoute prototypes ou démonstrations.
• Mal adapté aux produits en phase de découverte. Si vous ne savez pas encore quoi construire, le V figera la mauvaise réponse.

Modèle en V vs cascade vs Agile : quelle différence ?

Le modèle en V se distingue de la cascade en associant chaque phase de conception à son propre niveau de test et en planifiant ces tests tôt. Il se distingue de l’Agile parce qu’il est séquentiel et piloté par les spécifications plutôt qu’itératif. Le modèle en W est un raffinement du V qui ajoute une activité de test parallèle à chaque phase. Le comparatif ci-dessous résume les compromis.

En pratique, le V et le modèle en cascade sont proches parents : tous deux sont pilotés par le plan, utilisent des jalons de phase et conviennent aux exigences stables. L’atout du V est un test structuré et précoce, avec une traçabilité intégrée. Le développement logiciel Agile suit la philosophie inverse et optimise l’apprentissage et le changement. Le choix n’est généralement pas V ou Agile, mais quelle part de chacun, ce que traite la section sur l’hybride plus bas.

Quand le modèle en V est-il le bon choix pour le développement logiciel ?

Le modèle en V est le bon choix lorsque les exigences sont stables, que les défaillances seraient coûteuses ou dangereuses et que quelqu’un d’extérieur à l’équipe exigera une preuve des tests. Si la plupart des points ci-dessous s’appliquent à votre projet, le V, ou un hybride bâti sur lui, est un bon choix :

• Les exigences sont bien comprises et peu susceptibles de changer pendant la réalisation.
• Le système est critique pour la sécurité ou la mission : une défaillance pourrait blesser des personnes, arrêter l’activité ou causer de lourdes pertes financières.
• Une autorité, un organisme notifié ou un certificateur auditera vos preuves de développement et de test.
• Le logiciel est co-développé avec du matériel, si bien que les interfaces et la synchronisation doivent être spécifiées et testées niveau par niveau.
• Le contrat est au forfait ou à périmètre fixe, avec une recette liée à des critères convenus.
• Les critères d’acceptation peuvent être rédigés clairement dès le départ.
• Plusieurs fournisseurs construisent des parties du système et ont besoin de points d’intégration définis.

Le V est un mauvais choix pour un MVP en phase de lancement, une application grand public dont les fonctionnalités dépendent des retours du marché, ou tout projet au périmètre encore flou. Dans ces cas, une livraison itérative trouve plus vite le bon produit, et la traçabilité de type V peut être ajoutée plus tard si le produit entre sur un marché réglementé.

Comment le modèle en V est-il utilisé dans les secteurs réglementés ?

Les secteurs réglementés utilisent le modèle en V parce que leurs normes sont elles-mêmes construites autour d’activités de développement et de vérification appariées. Suivre le V fait des preuves de conformité un sous-produit du travail normal plutôt qu’un projet documentaire distinct en fin de parcours.

Automobile : ISO 26262 et Automotive SPICE 4.0

Le logiciel automobile est aujourd’hui le cas d’usage le plus clair du modèle en V. ISO 26262 (deuxième édition, 2018) organise le travail de sécurité fonctionnelle du concept à la conception système et à l’implémentation, puis à la vérification et la validation, une séquence qui se projette directement sur le V, comme le décrit SPEC Innovations dans son livre blanc sur le sujet. Automotive SPICE 4.0 définit des domaines de processus en descendant la branche gauche, des exigences et de la conception jusqu’à l’unité logicielle, et des tests de vérification en remontant la branche droite, de l’unité jusqu’au système, avec une traçabilité bidirectionnelle. Aptiv décrit son propre V automobile comme exigences système, conception système, exigences logicielles, implémentation, puis tests d’intégration et de qualification logiciels et système. Pour une vue d’ensemble, consultez notre guide du développement logiciel automobile.

Dispositifs médicaux : IEC 62304 et validation logicielle de la FDA

Le logiciel des dispositifs médicaux suit IEC 62304 (avec l’amendement 1 de 2015), qui exige planification du développement, exigences, architecture, conception détaillée, vérification unitaire, tests d’intégration et tests système, proportionnés à la classe de sécurité du logiciel. Cette liste, c’est le V sans en porter le nom. Aux États-Unis, le guide de la FDA sur la validation logicielle attend la preuve documentée que le logiciel répond aux besoins des utilisateurs et à l’usage prévu, exactement ce qu’apporte le niveau de recette du V. Plus de détails dans notre guide du développement logiciel pour dispositifs médicaux.

Aéronautique et défense : DO-178C

Le logiciel embarqué aéronautique est certifié selon DO-178C, publié en 2011. La norme exige des exigences de haut et de bas niveau, une traçabilité entre exigences, code et tests, et une analyse de couverture structurelle dont la rigueur augmente avec le niveau d’assurance de conception, jusqu’à la couverture MC/DC pour le logiciel le plus critique. L’association conception détaillée et tests unitaires du V, ainsi que sa RTM, offrent aux équipes un moyen naturel de démontrer ces preuves. Notre article sur le logiciel aéronautique présente le contexte de certification.

Secteur public : V-Modell XT et ingénierie système

Le standard fédéral allemand V-Modell XT prescrit un processus en V adaptable pour les projets informatiques du secteur public, en définissant rôles, produits et points de décision pour le donneur d’ordre comme pour le prestataire. Aux États-Unis, la Federal Highway Administration a utilisé le V dans ses guides d’ingénierie système pour les projets de transport intelligent, notamment le concept d’opérations Clarus de 2005. Les acheteurs publics privilégient le V parce qu’il rattache chaque étape de recette à une exigence contractuelle.

Le modèle en V est-il compatible avec l’Agile ? V hybride, modèle en W et Agile V en 2026

Oui. En 2026, le modèle en V sert le plus souvent de cadre de gouvernance et de preuve autour d’une livraison itérative, et non de séquence stricte en une seule passe. Les équipes conservent les niveaux, plans de test et traçabilité du V, et travaillent en itérations courtes à l’intérieur. Trois schémas sont courants.

Des sprints à l’intérieur du V. Exigences et architecture sont figées en haut du V pour une version ou un incrément. Dans la bande d’implémentation, les équipes travaillent en sprints : chaque sprint livre des fonctionnalités conçues, codées et testées en unitaire et en intégration, la mise à jour de la RTM faisant partie de la définition de terminé. Tests système et recette se déroulent au niveau de la version. C’est l’hybride le plus répandu aujourd’hui dans les programmes automobiles et médicaux.

Le modèle en W. Le modèle en W ajoute une activité de test en parallèle de chaque phase de développement : relire les exigences pendant leur rédaction, tester la conception pendant qu’elle est dessinée, et ainsi de suite. Dessiné, il ressemble à deux V qui se chevauchent, d’où son nom. Il pousse le shift-left testing plus loin que le V classique.

Agile V avec des agents d’IA. Un cadre publié sur arXiv en février 2026 par Koch et Wellbrock, nommé Agile V, intègre la vérification indépendante et la génération d’artefacts d’audit dans chaque cycle de tâche agile, avec des agents d’IA par étape et des points d’approbation humaine. Leur étude de faisabilité sur un système hardware-in-the-loop d’environ 500 lignes de code, 8 exigences et 54 tests a rapporté un taux de réussite de 100 % au niveau des exigences et estimé une réduction des coûts d’un facteur 10 à 50 par rapport à une base COCOMO II. Il s’agit d’une seule petite étude de cas, pas d’une référence sectorielle, mais elle montre où va le V : la génération automatisée de preuves au sein d’itérations rapides.

Les pipelines d’intégration continue rendent ces trois schémas praticables. Quand les tests unitaires et d’intégration s’exécutent à chaque commit et que les résultats sont liés aux identifiants d’exigences, la branche droite du V produit des preuves en continu plutôt qu’en un seul bloc tardif. La même idée sous-tend un cycle de développement logiciel sécurisé, et c’est une pratique courante en développement de logiciel embarqué, où les bancs hardware-in-the-loop tournent chaque nuit.

Mettre en œuvre le modèle en V : 7 bonnes pratiques

Un projet en V réussit quand la documentation sert l’ingénierie et non l’inverse. Ces sept pratiques gardent le modèle utile et léger.

1. Adaptez le V au risque du projet. Une fonction de freinage critique pour la sécurité exige chaque niveau et des revues indépendantes ; un outil de reporting interne peut fusionner HLD et LLD. Des normes comme V-Modell XT et IEC 62304 autorisent explicitement cette adaptation. Utilisez-la.
2. Rédigez les plans de test à chaque jalon de gauche. Ne clôturez aucune phase tant que son plan de test associé n’existe pas et n’a pas été relu. C’est le cœur du V ; sans cela, vous faites de la cascade.
3. Tenez une RTM vivante dans votre outil ALM. Gérez la traçabilité dans un outil de gestion du cycle de vie des applications ou un gestionnaire de tickets (Jira, Polarion et codeBeamer sont des choix courants) plutôt que dans un tableur, pour que les liens se mettent à jour à chaque changement.
4. Automatisez les tests unitaires et d’intégration dans la CI. Des tests automatisés liés aux identifiants d’exigences transforment le bas de la branche droite du V en preuve continue.
5. Menez revues et analyse statique à gauche. Inspectez exigences et conceptions avec des check-lists, et passez le code à l’analyse statique avant les tests unitaires. C’est là que le V tient sa promesse de prévention des défauts.
6. Gérez les changements avec une analyse d’impact des deux côtés. Chaque demande de changement doit lister les éléments de conception et les tests concernés. Avec la RTM, c’est une requête, pas une supposition.
7. Recourez à une vérification indépendante pour les niveaux critiques. Pour les niveaux d’intégrité les plus élevés, faites réaliser revues et tests par des personnes qui n’ont écrit ni le code ni la conception, comme l’attendent ISO 26262 et DO-178C.

Ces pratiques recoupent largement la discipline générale de l’assurance qualité. Le V donne simplement à chaque activité QA une place fixe et une phase partenaire.

FAQ

Dernière mise à jour le 2 octobre 2026. Sources : Wikipedia, V-model (software development) ; Aptiv, What Is the V-Model in Software Development? ; VDA QMC, Automotive SPICE PAM v4.0 (2023) ; Koch & Wellbrock, Agile V, arXiv 2602.20684 (2026) ; SPEC Innovations, ISO 26262 and the Systems Engineering V-Model ; Built In, What Is the V-Model in Software Development?. Normes : ISO 26262:2018, IEC 62304 (Amd 1:2015), DO-178C (2011). L’exemple de RTM est illustratif.