Modèles de développement logiciel : 15 documents gratuits pour chaque phase du projet

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Un modèle de développement logiciel est l’assurance la moins chère qu’un projet puisse souscrire. Sans lui, chaque nouveau projet réinvente ses documents à partir d’une page blanche : les exigences sont consignées sous une forme différente à chaque fois, les critères d’acceptation disparaissent, des litiges de périmètre éclatent parce que personne n’a écrit ce qui était exclu, et les versions partent avec des notes de version qui ne sont qu’un vidage des messages de commit.

Un bon kit de modèles règle ce problème en donnant à chaque tâche récurrente — planifier, contractualiser, spécifier, concevoir, construire, tester et livrer — une structure convenue avec un responsable clairement identifié. C’est le même kit que nous utilisons lorsque nous assurons nos services de product engineering pour les équipes logicielles en croissance : des documents courts qui vivent à côté du code et évoluent avec lui, et non des fichiers perdus dans un drive partagé oublié.

Ce guide vous propose quinze modèles de développement logiciel gratuits organisés selon les phases du cycle de vie du développement logiciel, un tableau récapitulatif indiquant le responsable de chacun et quand s’en passer, des squelettes de champs prêts à copier, le meilleur format pour chaque document, une méthode en sept étapes pour adapter les modèles à votre équipe, les erreurs fréquentes que nous observons dans les projets clients, et une FAQ.

Qu’est-ce qu’un modèle de développement logiciel ?

Un modèle de développement logiciel est un squelette de document réutilisable pour une tâche récurrente d’un projet logiciel — par exemple un plan de projet, une spécification des exigences, un document de conception, un plan de test ou des notes de version. Il fixe les sections, explique ce que doit contenir chaque champ et désigne la personne responsable du document, afin que chaque projet consigne les mêmes informations au même endroit.

Un modèle n’est pas de la documentation pour le plaisir. Sa valeur vient des décisions qu’il impose : ce qui est dans le périmètre et ce qui en est exclu, quelles exigences sont obligatoires, quels risques sont acceptés, comment un changement sera testé et qui valide une version. Un modèle que les équipes de développement réutilisent vraiment présente trois propriétés :

• Des sections fixes. Les mêmes titres dans le même ordre, pour que les lecteurs sachent où trouver le périmètre, les risques ou les critères d’acceptation dans n’importe quel projet.
• Des consignes dans chaque champ. Une ligne d’aide sous chaque titre (« listez ce qui est explicitement hors périmètre »), supprimée une fois le champ rempli.
• Un responsable nommé. Un rôle chargé de tenir le document à jour ; un modèle sans responsable devient obsolète dès le premier sprint.

Pourquoi utiliser des modèles de développement logiciel ?

Les équipes utilisent des modèles de développement logiciel parce qu’ils rendent visibles les informations manquantes avant qu’elles ne deviennent un défaut, un litige ou un retard. Un champ vide intitulé « hors périmètre » ou « plan de retour arrière » est bien plus difficile à ignorer qu’une question que personne n’a pensé à poser.

• Moins d’exigences oubliées. Des sections fixes pour les exigences non fonctionnelles, les contraintes et les critères d’acceptation empêchent les équipes de ne documenter que le scénario nominal.
• Une intégration plus rapide. Les nouveaux ingénieurs, testeurs et prestataires retrouvent la même structure dans chaque projet et deviennent productifs plus tôt.
• Des estimations et des propositions comparables. Quand chaque prestataire répond au même RFP et que chaque estimation suit la même décomposition, les comparaisons deviennent équitables.
• La traçabilité. Des identifiants qui relient l’exigence à la user story, au cas de test et à la note de version montrent exactement ce qui a été construit, testé et livré.
• Des audits et une conformité plus simples. Les projets réglementés peuvent présenter une trace documentaire cohérente sans sprint de documentation de dernière minute.
• Un meilleur contexte pour les assistants IA. Un modèle bien structuré donne aux assistants de code et de rédaction le contexte nécessaire pour produire un contenu utile plutôt qu’un texte générique.

De quels modèles avez-vous besoin à chaque phase ?

Chaque phase d’un projet logiciel nécessite un petit nombre de modèles : la planification et la contractualisation demandent un plan, un SOW, un RFP et une estimation ; les exigences, un PRD, une SRS et des user stories ; la conception, un document de conception et des ADR ; la réalisation, un plan de sprint et un modèle de PR ; les tests, un plan de test, un rapport de bug et une validation UAT ; la mise en production, des notes de version. Le tableau associe les quinze modèles à leur phase, à leur responsable et à leur cas d’usage.

Pour une équipe de cinq personnes ou moins, l’ensemble minimal viable comprend un plan de développement logiciel allégé, un PRD, des user stories avec critères d’acceptation, un modèle de pull request et des notes de version. Ces cinq documents couvrent la raison d’être du produit, ce qu’il faut construire, la revue des changements et ce qui a réellement été livré ; tout le reste s’ajoute lorsque le risque, la réglementation ou la taille de l’équipe le justifient.

15 modèles gratuits pour le développement logiciel, par phase

Les quinze modèles gratuits pour le développement logiciel ci-dessous sont regroupés par phase du cycle de vie, et chacun s’accompagne d’une définition, des situations où l’utiliser, d’un squelette de champs prêt à copier et d’un conseil pratique. Lorsque nous avons consacré un guide détaillé avec un exemple complet, le squelette reste court et renvoie vers ce guide.

Modèles de planification et de contrat

Les modèles de planification et de contrat définissent pourquoi le projet existe, ce qui sera livré, par qui, pour quel montant et selon quelles hypothèses. Ce sont les documents les plus souvent négligés sur les petits projets et les plus souvent regrettés quand le périmètre est contesté.

1. Plan de développement logiciel

Un modèle de plan de développement logiciel est un document unique qui décrit les objectifs, le périmètre, l’équipe, le calendrier, les risques et les règles de communication du projet. Utilisez-le dès que plusieurs équipes sont impliquées, qu’une échéance est fixe ou qu’un sponsor extérieur à l’équipe doit approuver le budget.

• Objectifs et indicateurs de succès (charte)
• Dans le périmètre / hors périmètre
• Équipe, rôles et décideurs
• Jalons et calendrier
• Registre des risques : risque, probabilité, impact, responsable, atténuation
• Dépendances et hypothèses
• Rythme de communication et de reporting

Conseil : gardez le registre des risques dans le plan plutôt que dans un fichier séparé, et revoyez-le à chaque jalon. Un modèle complet et un exemple détaillé figurent dans notre guide modèle de plan de projet de développement logiciel.

2. Énoncé des travaux (SOW)

Un modèle d’énoncé des travaux définit précisément ce qu’un prestataire livrera, comment se déroule la recette et comment les changements sont gérés. Utilisez-le pour toute mission où une équipe externe écrit du code pour vous, que le contrat soit au forfait ou en régie.

• Contexte et objectifs
• Livrables avec critères d’acceptation
• Éléments hors périmètre
• Calendrier et jalons
• Rôles et responsabilités des deux parties
• Procédure de demande de changement
• Échéancier de paiement lié aux jalons

Conseil : la liste des éléments hors périmètre évite plus de litiges que n’importe quelle autre section. L’aspect juridique de l’accord est traité dans notre guide du contrat de développement logiciel.

3. Appel d’offres (RFP)

Un modèle d’appel d’offres est le document que vous envoyez à plusieurs prestataires pour que leurs propositions répondent aux mêmes questions dans la même structure. Utilisez-le lorsque vous comparez deux partenaires de développement ou plus.

• Contexte de l’entreprise et du produit
• Objectifs métier et indicateurs de succès
• Périmètre fonctionnel et parcours utilisateurs clés
• Contraintes techniques et intégrations
• Fourchette budgétaire et calendrier
• Format de proposition attendu et critères d’évaluation

Conseil : publiez les critères d’évaluation et leur pondération dans le RFP lui-même ; les prestataires optimisent alors leur réponse pour ce qui compte vraiment pour vous. Consultez notre guide du RFP de développement logiciel pour un modèle complet.

4. Feuille d’estimation et de budget

Un modèle de feuille d’estimation et de budget transforme le périmètre en effort et en coût dans une structure que chacun peut auditer. Utilisez-le pour la validation budgétaire, pour comparer des devis de prestataires et pour toute offre au forfait.

• Structure de découpage du travail (epics et fonctionnalités)
• Estimation à trois points par élément : optimiste, la plus probable, pessimiste
• Rôles et taux moyens pondérés
• Effort hors développement : QA, DevOps, gestion de projet, design
• Réserve pour aléas et justification de son montant
• Hypothèses dont dépend l’estimation

Conseil : un tableur est le bon format ici, car les formules gardent les totaux justes lorsque les éléments changent. Notre guide de l’estimation de projet logiciel explique les techniques derrière chaque colonne.

Modèles d’exigences

Les modèles d’exigences décrivent ce que le produit doit faire et comment vous saurez qu’il le fait. La plupart des équipes ont besoin d’un PRD et de user stories ; les projets réglementés ou pilotés par contrat y ajoutent une SRS formelle.

5. Document d’exigences produit (PRD)

Un modèle de PRD décrit un produit ou une fonctionnalité du point de vue de l’utilisateur et du métier : le problème, qui le rencontre, à quoi ressemble le succès et ce qui entre dans le périmètre. Utilisez-le pour chaque nouveau produit et pour chaque fonctionnalité assez importante pour nécessiter plus d’un sprint.

• Énoncé du problème et utilisateurs cibles
• Objectifs et indicateurs de succès
• Parcours utilisateurs ou cas d’usage
• Périmètre fonctionnel (must / should / could)
• Non-objectifs
• Questions ouvertes et dépendances
• Critères de mise en production

Conseil : rédigez les non-objectifs avant les objectifs ; cela force les conversations difficiles dès le début. La structure complète figure dans notre guide du document d’exigences produit.

6. Spécification des exigences logicielles (SRS)

Un modèle de spécification des exigences logicielles liste des exigences numérotées et testables pour le système, fonctionnelles comme non fonctionnelles. Utilisez-le pour les travaux réglementés, critiques pour la sécurité ou pilotés par contrat, où chaque exigence doit être vérifiée et tracée. La référence internationale est la norme ISO/IEC/IEEE 29148:2018, qui définit une famille de documents d’exigences (spécifications des exigences métier, des parties prenantes, du système et du logiciel) et énumère neuf caractéristiques d’une exigence individuelle bien formulée — nécessaire, appropriée, non ambiguë, complète, singulière, réalisable, vérifiable, correcte et conforme — ainsi que cinq pour l’ensemble des exigences.

• Objet, périmètre et public visé
• Définitions et abréviations
• Exigences fonctionnelles, chacune avec un identifiant unique
• Exigences non fonctionnelles : performance, sécurité, disponibilité, accessibilité
• Interfaces externes : utilisateurs, matériel, logiciel, communications
• Contraintes et hypothèses
• Méthode de vérification par exigence (test, inspection, analyse, démonstration)

Conseil : attribuez à chaque ligne d’exigence un identifiant tel que FR-012 et réutilisez-le dans les cas de test et les notes de version. Un logiciel de gestion des exigences dédié devient utile dès que la liste dépasse quelques centaines d’éléments.

7. User story et critères d’acceptation

Un modèle de user story capture une petite unité de valeur pour l’utilisateur ainsi que les conditions qui prouvent qu’elle fonctionne. Utilisez-le pour chaque élément d’un backlog agile ; les bonnes stories suivent la grille INVEST — indépendante, négociable, porteuse de valeur, estimable, petite et testable.

Story :  En tant que [type d'utilisateur], je veux [objectif] afin de [bénéfice].
ID :     US-___   Liens : section du PRD / FR-___
Critères d'acceptation (Given / When / Then) :
  Given [contexte]
  When  [action]
  Then  [résultat observable]
Notes :  cas limites, événements analytics, lien vers la maquette

Conseil : si vous ne parvenez pas à écrire au moins une ligne Given/When/Then, la story n’est pas prête pour un sprint.

Modèles de conception

Les modèles de conception consignent comment le système sera construit et pourquoi certaines options ont été retenues. Ce sont les documents que les nouveaux ingénieurs lisent en premier et ceux qui font gagner le plus de temps lorsqu’une décision est remise en question un an plus tard.

8. Document de conception logicielle (SDD)

Un modèle de document de conception logicielle explique comment un nouveau service, module ou intégration fonctionnera avant que l’essentiel du code ne soit écrit. Utilisez-le pour les nouveaux services, les modèles de données, les intégrations externes et tout ce qui comporte un risque de sécurité ou de performance. IEEE 1016, la norme des descriptions de conception logicielle, constitue une liste de contrôle utile des points de vue à couvrir.

• Contexte, objectifs et non-objectifs
• Vue d’ensemble de l’architecture et schéma
• Modèle de données et stockage
• API et contrats
• Alternatives envisagées et raisons de leur rejet
• Aspects de sécurité, de confidentialité et de conformité
• Plan de déploiement, de supervision et de retour arrière

Conseil : limitez la longueur du document (quelques pages suffisent généralement) et faites-le relire par au moins un ingénieur d’une autre équipe.

9. Architecture decision record (ADR)

Un modèle d’architecture decision record consigne une décision technique importante, son contexte et ses conséquences dans un fichier court. Utilisez-le pour toute décision coûteuse à annuler : une base de données, un framework, un modèle d’intégration, un mode d’hébergement. Le format vient de l’article publié en 2011 par Michael Nygard, Documenting Architecture Decisions.

# ADR-007 : [titre court de la décision]
Statut :       Proposé | Accepté | Remplacé par ADR-___
Contexte :     Quelles forces et contraintes ont conduit à cette décision ?
Décision :     Ce que nous allons faire, en phrases complètes.
Conséquences : Ce qui devient plus facile, plus difficile, ce que nous acceptons.

Conseil : stockez une décision par fichier dans docs/adr/ au sein du dépôt et ne modifiez jamais un ADR accepté — remplacez-le par un nouveau.

Modèles de réalisation

Les modèles de réalisation assurent la cohérence de la livraison au quotidien : ce sur quoi l’équipe s’engage pendant un sprint et ce que chaque modification de code doit expliquer avant d’être fusionnée.

10. Plan de sprint et product backlog

Un modèle de plan de sprint consigne l’objectif du sprint, la capacité de l’équipe et les éléments du backlog sur lesquels l’équipe s’engage. Utilisez-le pour toute livraison itérative en sprints de durée fixe ; dans un flux Kanban pur, conservez le format du backlog et abandonnez les champs propres au sprint.

• Objectif du sprint (une phrase)
• Dates et capacité de l’équipe (jours-personne, congés)
• Éléments du backlog engagés, avec estimations
• Éléments optionnels (stretch)
• Dépendances et risques de ce sprint
• Definition of Done

Conseil : rédigez la Definition of Done une seule fois au niveau de l’équipe et faites-y référence ; ne la recopiez pas à chaque sprint. Plus de détails sur les cérémonies associées dans notre guide de Scrum.

11. Modèle de pull request

Un modèle de pull request est un fichier Markdown qui pré-remplit la description de chaque pull request, pour que les relecteurs disposent toujours du contexte nécessaire. Utilisez-le dans chaque dépôt avec revue de code. Sur GitHub, il se trouve dans .github/pull_request_template.md, comme l’explique la documentation GitHub.

## Quoi et pourquoi
## Ticket lié
## Comment cela a-t-il été testé ?
## Captures d'écran (changements d'UI)
## Risque et plan de retour arrière
## Checklist
- [ ] Tests ajoutés ou mis à jour
- [ ] Docs / changelog mis à jour
- [ ] Aucun secret ni donnée personnelle dans le diff

Conseil : limitez-le à moins de dix lignes ; les modèles de PR trop longs sont supprimés plutôt que remplis. Le contexte du processus de revue est détaillé dans notre article sur la pull request.

Modèles de test

Les modèles de test définissent comment la qualité est vérifiée, comment les défauts sont signalés et comment le client accepte formellement le résultat. La norme ISO/IEC/IEEE 29119-3:2021 est la référence pour la documentation de test : elle définit des documents tels que le plan de test, les rapports d’état et de fin de test, les spécifications de conception, de cas et de procédures de test ainsi que les exigences relatives aux données de test, et elle peut s’utiliser avec n’importe quel modèle de cycle de vie.

12. Plan de test et cas de test

Un modèle de plan de test décrit ce qui sera testé, comment, où et par qui ; un modèle de cas de test décrit une vérification précise avec son résultat attendu. Utilisez-les pour toute version qui implique de vrais utilisateurs, de l’argent ou des données.

Champs du plan de test :

• Périmètre et fonctionnalités non testées
• Approche et niveaux de test (unitaire, intégration, de bout en bout, performance, sécurité)
• Environnements et données de test
• Critères d’entrée et de sortie
• Calendrier et rôles
• Risques et plans de secours

Champs du cas de test : identifiant, exigence liée, préconditions, étapes, résultat attendu, résultat obtenu, statut.

Conseil : gardez les cas de test dans un tableur ou un outil de gestion des tests et reliez chacun à un identifiant d’exigence. Notre guide de l’assurance qualité en développement logiciel couvre le processus QA dans son ensemble.

13. Rapport de bug

Un modèle de rapport de bug rend chaque défaut reproductible dès la première lecture. Utilisez-le dès qu’une personne extérieure à l’équipe principale — testeurs, clients, support — signale des problèmes.

• Titre court et précis
• Environnement et version (appareil, navigateur, build)
• Étapes de reproduction
• Résultat attendu vs résultat obtenu
• Gravité et priorité
• Preuves : captures d’écran, logs, vidéo

Conseil : sur GitHub, transformez-le en formulaire d’issue dans .github/ISSUE_TEMPLATE/ pour que les champs obligatoires ne puissent pas être ignorés.

14. Validation UAT

Un modèle de validation UAT atteste que le client a testé les scénarios convenus et accepte la version, les défauts connus étant explicitement acceptés. Utilisez-le pour la recette client, les paiements par jalon et les décisions de mise en production.

• Identifiant de la version ou du jalon
• Scénarios de test exécutés, avec réussite / échec
• Défauts ouverts acceptés pour la mise en production, avec leur gravité
• Conditions d’acceptation
• Nom, rôle et date de l’approbateur

Conseil : convenez des scénarios UAT au moment de la signature du SOW, et non la semaine précédant la mise en production. Plus de détails dans notre guide des tests d’acceptation utilisateur.

Modèles de mise en production

Les modèles de mise en production indiquent aux développeurs et aux utilisateurs ce qui a changé. Un changelog s’adresse aux développeurs et aux intégrateurs ; les notes de version s’adressent aux utilisateurs et expliquent le changement en termes de bénéfice.

15. Notes de version et changelog

Un modèle de notes de version liste ce qui est nouveau, amélioré et corrigé dans une version, dans un langage compréhensible par les utilisateurs ; un changelog liste chaque changement notable à l’intention des développeurs. La convention très répandue Keep a Changelog 1.1.0 regroupe les changements sous Added, Changed, Deprecated, Removed, Fixed et Security, et se combine bien avec Semantic Versioning 2.0.0, où les versions sont numérotées MAJOR.MINOR.PATCH.

## [2.4.0] - 2026-10-25
### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security

Conseil : rédigez les notes de version à partir du changelog, et non des messages de commit, et commencez par le changement que les utilisateurs remarqueront en premier.

Word, Google Docs, Excel ou Markdown : quel format fonctionne le mieux ?

Le meilleur format dépend de la fréquence à laquelle le document change et de qui le modifie : les documents qui évoluent avec le code ont leur place en Markdown dans le dépôt, les contrats et les validations dans Word ou Google Docs, et tout ce qui contient des chiffres dans un tableur.

Les modèles de développement logiciel gratuits s’assemblent le plus facilement à partir de trois sources : les squelettes de ce guide, les modèles de pull request et d’issue que GitHub prend en charge dans chaque dépôt, et des normes publiques telles que ISO/IEC/IEEE 29148 et 29119-3 utilisées comme listes de contrôle. Évitez de copier mot pour mot des kits de modèles commerciaux ; leurs champs sont pensés pour l’outil de l’éditeur, pas pour votre processus.

Comment adapter un modèle à votre équipe ?

Adaptez un modèle en commençant petit, en supprimant tous les champs que personne n’utilise et en reliant les documents par des identifiants communs. Un modèle qui correspond à la façon dont votre équipe travaille réellement est rempli ; un modèle générique est ignoré. Ces sept étapes fonctionnent pour des équipes de toutes tailles :

1. Commencez par cinq documents. Plan allégé, PRD, user stories, modèle de PR et notes de version ; n’en ajoutez d’autres que lorsqu’un vrai problème apparaît.
2. Supprimez les champs inutilisés. Si un champ est resté vide pendant deux sprints, supprimez-le ou fusionnez-le avec un autre.
3. Nommez un responsable pour chaque modèle. Un rôle le tient à jour et approuve les modifications de sa structure.
4. Gardez les modèles sous gestion de versions. Stockez-les dans le dépôt ou dans un espace versionné, pour que chaque modification ait un auteur, une date et une raison.
5. Reliez tout par des identifiants. Exigence → user story → cas de test → note de version, avec les mêmes identifiants tout du long.
6. Revoyez le kit chaque trimestre. Profitez des rétrospectives pour ajouter les champs qui auraient évité un vrai défaut ou un vrai litige.
7. Automatisez les contrôles. Utilisez des checklists de PR, des champs obligatoires dans les formulaires d’issue et une étape de CI qui échoue lorsque le changelog n’est pas mis à jour.

Chaque type de mission demande une profondeur différente : un contrat au forfait exige un SOW détaillé et une validation UAT, un MVP en régie peut fonctionner avec un PRD, un backlog et des notes de version, et un produit réglementé a besoin de la SRS et d’une documentation de test formelle dès le départ.

L’IA peut-elle remplir les modèles de développement logiciel ?

Oui, les assistants IA peuvent remplir les modèles de développement logiciel sous forme de premier jet, mais ce sont toujours des personnes qui doivent prendre et approuver les décisions. Le modèle fournit la structure, l’assistant rédige le contenu et un responsable identifié vérifie chaque exigence, chaque risque et chaque critère d’acceptation.

L’adoption est déjà quasi universelle. Le rapport DORA 2025 State of AI-assisted Software Development de Google indique que 90 % des professionnels du logiciel utilisent l’IA au travail, soit 14 % de plus que l’année précédente, avec une médiane de deux heures par jour. Plus de 80 % estiment que l’IA a amélioré leur productivité et 59 % constatent un effet positif sur la qualité du code — pourtant, seuls 24 % font « beaucoup » ou « énormément » confiance aux résultats de l’IA, tandis que 30 % lui font « un peu » ou « pas du tout » confiance. Les recherches de DORA indiquent aussi que relier les outils d’IA à la documentation interne permet d’améliorer la qualité de ce qu’ils produisent (dora.dev).

C’est précisément sur ce déficit de confiance que les modèles aident. Un processus pratique :

• Donnez à l’assistant le modèle, la section pertinente du PRD et les comptes rendus de réunion.
• Demandez-lui de remplir chaque champ et de lister les informations manquantes plutôt que de les inventer.
• Faites relire chaque exigence, estimation et risque ligne par ligne par le responsable du document.
• Ne collez jamais d’exigences client confidentielles dans un outil que votre entreprise n’a pas approuvé pour ces données.

Quelles sont les erreurs de modèle les plus fréquentes et comment les corriger ?

L’erreur la plus fréquente consiste à traiter le modèle comme un objectif en soi plutôt que comme le support des décisions qu’il doit consigner. Les corrections consistent presque toujours à rendre les modèles plus courts, dotés d’un responsable et reliés entre eux.

Quels modèles comptent le plus pour les projets agiles ou en cascade ?

Les projets en cascade et réglementés s’appuient surtout sur des modèles formels établis en amont — SRS, SDD, un plan de test aligné sur ISO/IEC/IEEE 29119-3 et une validation UAT formelle — tandis que les projets agiles s’appuient sur des modèles légers et mis à jour en continu : un product backlog, des user stories, une Definition of Done, des ADR, un modèle de PR et un changelog.

• Cascade ou réglementé : plan de développement logiciel, SOW, SRS avec méthodes de vérification, SDD, plan de test et rapport de fin de test, validation UAT.
• Agile : PRD allégé, backlog et user stories, Definition of Done, ADR, modèle de PR, rapport de bug, changelog et notes de version.
• Hybride : SOW, SRS et UAT formels au niveau du contrat, avec des modèles agiles pour la livraison quotidienne au sein de chaque jalon.

Pour une comparaison plus approfondie des deux modèles de livraison eux-mêmes, lisez notre guide des méthodologies de développement logiciel, qui oppose notamment l’agile et la cascade.

FAQ

Publié le 25 octobre 2026. Sources : Google, DORA 2025 State of AI-assisted Software Development ; DORA, Balancing AI tensions ; ISO/IEC/IEEE 29148:2018, Requirements engineering ; ISO/IEC/IEEE 29119-3, Test documentation ; IEEE 1016-2009, Software Design Descriptions ; M. Nygard, Documenting Architecture Decisions, 2011 ; Keep a Changelog 1.1.0 ; Semantic Versioning 2.0.0 ; GitHub Docs, Creating a pull request template. Les squelettes de modèles sont donnés à titre indicatif et doivent être adaptés à votre processus.