Un bon plan de test est ce qui empêche les bugs d’atteindre la production. Avec Trupeer, vous pouvez gagner des heures sur la planification des tests en commençant par un modèle de plan de test gratuit, en le personnalisant avec vos directives de marque, puis en transformant les plans de test en visites vidéo qui alignent l’ingénierie, le produit et le QA.

Qu’est-ce qu’un modèle de plan de test gratuit ?

Un modèle de plan de test gratuit est une structure réutilisable du document qui indique ce qui sera testé pour une version ou un projet donné, dans quels environnements, par qui, selon quel calendrier, et comment vous saurez que les tests sont terminés.

La liste des sections est standard et sans controverse. Périmètre, approche, environnements, ressources, calendrier, critères d’entrée, critères de sortie, risques, livrables. Chaque modèle publié les inclut, et ils sont restés largement stables depuis que les traditions ISO et IEEE les ont établis il y a des décennies.

Le modèle n’est pas l’endroit où les plans de test échouent. Ils échouent à un moment précis, des mois après l’approbation du plan, et l’échec a toujours la même forme.

Le format suit l’usage. Un fichier Word de modèle de plan de test gratuit convient au plan lui-même, qui est un texte qui fait l’objet d’une relecture et d’un accord, et pour une petite version, une mise en page Word simple d’un ou deux pages suffit. Une version Excel d’un modèle de plan de test gratuit convient au calendrier, à la matrice de couverture et à la planification des ressources. Un modèle de plan de test gratuit au format PDF est la copie approuvée jointe au dossier de version, et un exemple de document de plan de test au format PDF provenant d’une source publiée est la meilleure façon de voir comment faire correctement.

Les plans de test se lisent une fois, puis on en discute plus tard

Un plan de test est rédigé des semaines avant le début des tests, quand personne n’est sous pression. Il est relu calmement, approuvé, puis classé.

Ensuite, il est relu à une seule occasion : le jour où quelqu’un veut expédier et que les tests ne sont pas terminés.

À ce moment-là, tout le monde dans la salle est concerné. La date a été communiquée. Les clients l’attendent. Le marketing a planifié quelque chose. L’équipe d’ingénierie travaille sur ce sujet depuis des semaines et aimerait que ce soit terminé. Et quelqu’un ouvre le plan de test, lit les critères de sortie, et découvre qu’ils ne règlent rien.

Tous les défauts prioritaires résolus. La suite de régression est passée. L’accord pour l’UAT est obtenu.

Chacun de ces éléments semble solide, mais aucun ne tient sous pression, pour des raisons abordées dans la section suivante. La décision se prend donc comme elle devait toujours se prendre, par la personne la plus senior et la plus impliquée, et le plan de test fournit un document sur lequel s’appuyer plutôt qu’une contrainte.

La valeur entière de rédiger un plan de test à l’avance, c’est que les décisions prises calmement sont meilleures que celles prises à neuf heures du soir un jeudi. Cette valeur n’est réalisée que si les décisions ont réellement été prises, et dans la plupart des plans, elles n’ont été que décrites.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Accédez à la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à apporter des changements au modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Après avoir effectué tous les changements nécessaires, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Aperçu et ajustements fins du modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez l’Aperçu.

À partir de l’écran d’aperçu, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.

Avec un modèle de plan de test, vous pouvez :

• Gagner du temps sur la rédaction : ignorez la page blanche grâce à une structure conçue pour le QA.

• Améliorer la couverture des tests : des sections intégrées garantissent qu’aucun élément critique n’est oublié.

• Rester conforme à votre marque : appliquez votre logo, vos polices et vos couleurs à l’aide du brand kit de Trupeer.

• Standardiser d’une version à l’autre : utilisez le même modèle de plan de test pour chaque produit et chaque version.

• Rester prêt pour l’audit : aligné sur IEEE 829, ISO 29119 et des normes similaires.

• Atteindre des équipes internationales : traduisez les plans de test en 65+ langues en un clic.

Rédigez d’abord les critères de sortie, et indiquez qui peut les lever

Deux changements, tous deux peu coûteux, et ils constituent l’argument entier de cette page.

Rédigez les critères de sortie avant tout le reste dans le plan. Avant le périmètre, avant l’approche, avant le calendrier. Cela inverse l’ordre habituel et force la question la plus difficile à passer en premier, quand il s’agit d’une discussion plutôt que d’une négociation. Tout le reste du plan existe pour satisfaire les critères de sortie, donc les décider en premier a aussi tendance à produire un plan plus court.

Indiquez qui peut lever chacun d’eux. Pas l’équipe. Une personne, par rôle, et spécifiquement pas la personne dont le travail consiste à expédier.

L’autorité de levée est le changement qui fait le travail. Les critères de sortie sont presque jamais formellement remplacés, car il n’existe aucun mécanisme pour les remplacer ; ils sont donc plutôt réinterprétés. Un défaut est reclassé. Un critère est lu avec plus de souplesse. Quelqu’un signe quelque chose qu’il n’a pas vérifié.

La réinterprétation est invisible et ne laisse aucune trace. Une levée est visible, nécessite qu’une personne nommée y appose son nom, et produit quelque chose que vous pouvez consulter ensuite. Cette différence modifie le comportement avant de modifier quoi que ce soit d’autre, car reclasser un défaut en réunion est facile, tandis que signer une levée ne l’est pas.

Ajoutez un champ supplémentaire : lorsque qu’un critère est levé, indiquez quelle action compensatoire est mise en place. Expédier d’abord à 10 % des clients, ou avec un rollback préparé, ou avec une équipe support briefée. Une levée sans compensation n’est qu’une décision d’accepter le risque, ce qui est parfois justifié et devrait au moins être indiqué comme tel.

Rendre les critères de sortie applicables

Trois propriétés, et la plupart des critères publiés n’en ont aucune.

Un nombre. Pas « suite de régression passée », mais « suite de régression : 100 % des cas prioritaires un exécutés, 95 % passés, zéro échec prioritaire un ouvert ». « Passé » et « exécuté » sont deux choses différentes, et un plan qui ne les distingue pas indiquera 90 % passés sur une suite qui n’avait été exécutée qu’à 60 %.

Un vérificateur qui n’est pas la personne sous pression. La classification de la sévérité est le point faible de chaque processus de test, car les personnes qui classifient les défauts sont fréquemment celles qui veulent expédier. Nommer qui attribue la sévérité, et faire en sorte que ce soit quelqu’un en dehors de la chaîne de livraison, supprime la voie la plus simple pour contourner un critère.

Une autorité de levée nommée. Comme indiqué plus haut, et elle doit être une personne différente du responsable de la version.

Un audit utile sur un plan existant. Lisez les critères de sortie et demandez, pour chacun, ce que quelqu’un devrait faire pour les contourner sans mentir. Si la réponse est disponible en moins de dix secondes, le critère a besoin d’un nombre et d’un vérificateur.

Ce qu’un modèle de plan de test doit contenir

Dix composants, avec les critères de sortie en premier.

Les lignes « environnements » et « données de test » méritent plus d’espace que ce que les modèles leur donnent. Un grand nombre de défauts qui atteignent la production n’ont pas été manqués par des cas de test faibles. Ils étaient inaccessibles, parce que l’environnement de test contenait un millier d’enregistrements alors que la production en a quatre millions, ou parce que la condition de timing qui les déclenche ne peut pas se produire sur une seule machine.

Modèle de plan de test gratuit : la structure à copier

Rempli avec un exemple réel plutôt que des placeholders. Le système est un logiciel de point de vente pour les supérettes.

Copiez depuis ici.

Critères de sortie. Rédits en premier, avec des nombres, des vérificateurs et une autorité de levée.

Les levées sont consignées par écrit avec l’action compensatoire, avant la version, et non après.

Critères d’entrée. Version déployée sur la préproduction. Test de fumée passé. Données de test chargées et actualisées. Aucun défaut prioritaire un ouvert provenant du cycle précédent.

Périmètre. Dans le périmètre : transactions en caisse, remboursements, rapprochement de fin de journée, mode hors ligne et le nouveau moteur de promotions. Hors périmètre : la suite de reporting du back office, inchangée dans cette version ; la certification du matériel pour de nouveaux périphériques, traitée séparément ; et les intégrations avec des fournisseurs tiers de fidélité, couvertes par leurs propres tests fournisseurs et acceptées sur cette base, ce qui constitue un risque consigné ci-dessous.

Approche. Régression automatisée pour les parcours caisse et remboursement existants. Tests exploratoires manuels sur le moteur de promotions, qui est nouveau. Tests de performance sur un pic simulé. Mode hors ligne testé en débranchant physiquement, et non via une simulation.

Environnements. Préproduction, avec une base de données restaurée à partir d’une capture de production d’un grand parc de magasins. Quatre caisses physiques de deux générations de matériel. Notez que la préproduction dispose d’un seul serveur d’application alors que la production en a six ; le comportement d’équilibrage de charge n’est donc pas représenté, et il s’agit d’un risque déclaré.

Données de test. Capture de production, anonymisée, actualisée chaque semaine. Inclut au moins un magasin avec plus de cinquante mille transactions historiques, car des défauts liés au volume sont apparus auparavant.

Calendrier et fenêtre. Trois semaines. Exécution estimée : onze jours d’effort pour deux testeurs, soit quatorze jours ouvrés sur une fenêtre de quinze jours. Un jour de contingence, faible, consigné comme un risque.

Ressources. Deux testeurs, à temps plein. Un ingénieur performance pendant trois jours. Responsable métier pendant deux jours pour l’UAT. Si l’un des testeurs est mobilisé sur le support, la fenêtre ne tient plus et le critère deux est le premier à être en risque.

Risques. Un serveur d’application unique en préproduction. Un jour de contingence de calendrier. Intégration de fidélité tierce non testée par nous. Responsable métier nouvellement en poste.

Livrables. Résultats de tests exécutés avec preuves, rapports de défauts, rapport de synthèse des tests, et le registre de levée signé le cas échéant.

Copiez depuis ici.

Exemple de plan de test : trois défauts prioritaires qui sont devenus deux

Danecroft Retail Systems fournit un logiciel de point de vente aux supérettes et emploie environ cent quatre-vingts personnes. Elle a publié une version majeure pour un parc de trois cent quarante magasins.

Le plan de test était un plan normal. Ses critères de sortie indiquaient : tous les défauts prioritaires résolus, suite de régression passée, validation UAT obtenue.

Le jour de la décision de version, trois défauts prioritaires étaient ouverts. La suite de régression avait été exécutée à 91 %, et le plan ne distinguait pas « exécuté » de « passé ». L’UAT avait été signée par un responsable produit en poste depuis cinq semaines.

Le responsable de version l’a signalé au CTO. Le CTO a demandé si les trois défauts étaient vraiment prioritaires.

Deux ont été reclassés en moyen pendant cette réunion. Le troisième a été accepté sur la base qu’un contournement existait.

Personne n’avait menti et personne n’avait remplacé quoi que ce soit. Le plan ne définissait pas ce qu’était un défaut prioritaire, ne précisait pas qui attribuait la sévérité, ne fixait aucun seuil sur l’exécution de la régression, et ne nommait aucune autorité de levée. Il n’y avait rien à remplacer, donc il n’y avait rien à consigner.

L’un des deux défauts reclassés a provoqué des gels de caisse dans une condition spécifique de promotions. Il apparaissait au pic des transactions le samedi, sur l’ensemble du parc. Le détaillant a estimé les ventes perdues à environ huit cent quatre-vingt-dix mille livres, a appliqué une pénalité contractuelle et Danecroft a crédité plusieurs mois de frais.

La revue a identifié trois faiblesses précises, toutes dans les critères de sortie et aucune dans les tests.

La sévérité était attribuée par les personnes sous pression pour expédier. « Passé » et « exécuté » étaient utilisés de manière interchangeable, donc 91 % semblait correspondre à un taux de réussite. Et la validation ne nommait aucun individu et ne précisait rien sur ce qu’ils confirmaient avoir fait.

La réécriture a donné à chaque critère un nombre, a nommé un vérificateur en dehors de la chaîne de livraison, a nommé une autorité de levée qui n’était pas le responsable de version, et a exigé que les levées soient consignées par écrit avec une action compensatoire.

Sur les six versions suivantes, deux levées ont été émises. Les deux ont été consignées, les deux comportaient une action compensatoire, et aucun défaut n’a été reclassé pendant une réunion de décision de version.

Les tests avaient été adéquats. Le plan n’avait fourni aucun mécanisme permettant aux tests d’avoir un impact.

Comment rédiger un plan de test en six étapes

1. Rédigez d’abord les critères de sortie, avec des nombres, avant tout le reste dans le document.

2. Nommer un vérificateur pour chacun, et assurez-vous que ce n’est pas quelqu’un dont les objectifs incluent la date de sortie.

3. Nommer une autorité de levée pour chacun, y compris les critères qui ne peuvent pas du tout être levés. Avoir au moins un critère qui ne peut pas être levé, c’est ce qui rend les autres significatifs.

4. Rédigez le périmètre, y compris ce qui est exclu, et expliquez pourquoi chaque exclusion est acceptable.

5. Décrivez l’environnement honnêtement, en particulier là où il diffère de la production d’une manière qui pourrait masquer des défauts.

6. Faites le calcul du calendrier et consignez la contingence, afin que lorsque la fenêtre se resserre, la discussion porte sur les critères en risque plutôt que sur le fait de savoir si les tests sont presque terminés.

L’étape trois est celle qui change les résultats. Un plan où tout peut être levé par la personne qui expédie est une description d’intentions.

Périmètre et ce que vous ne testez pas

La section « hors périmètre » est la deuxième partie la plus précieuse d’un plan de test et elle tient généralement sur une seule ligne dans la plupart des plans.

Trois catégories doivent y figurer, et elles sont différentes.

Exclu délibérément parce que c’est inchangé. Raisonnable, et utile à préciser avec la raison, car « inchangé » est une hypothèse qui s’avère parfois fausse.

Exclu parce que quelqu’un d’autre le teste. Composants tiers, intégrations fournisseurs, certification du matériel. Indiquez qui le teste et sur quelles preuves vous acceptez ce résultat. C’est ici que le risque se transfère silencieusement.

Exclu parce qu’il ne peut pas être testé ici. Comportement d’équilibrage de charge, réseaux de paiement réels, volumes de données de production, concurrence réelle. Ce sont les cas honnêtes, et ils doivent apparaître dans la section « risques » ainsi que dans la section « périmètre », car ils nomment les défauts que votre processus ne peut pas détecter.

La troisième catégorie est celle qui prédit les incidents en production. Une équipe capable de lister ce que ses tests ne peuvent pas atteindre est une équipe qui sait où chercher quand quelque chose tourne mal.

Plan de test, stratégie de test ou cas de test ?

Trois niveaux, et la confusion entre eux est suffisamment fréquente pour qu’il soit utile de les énoncer clairement.

Une stratégie de test est organisationnelle. Comment cette entreprise teste, quels types de tests elle utilise, quelles normes s’appliquent. Rédite une fois, elle s’applique à l’ensemble des projets.

Un plan de test est spécifique à une version ou à un projet. Cette page.

Un cas de test est un seul contrôle, avec des étapes et un résultat attendu. La page modèles de documentation de test couvre ces éléments, y compris pourquoi le résultat attendu est l’endroit où la plupart des suites de tests se trompent.

Au-dessus des trois se trouve le plan QA, qui couvre tout ce qui est fait pour prévenir les défauts plutôt que pour les trouver : revue des exigences, définition du « done », normes de revue du code. Le modèle de plan QA couvre cette distinction. Si votre plan QA ne contient que des tests, vous avez rédigé un plan de test avec un titre plus large.

Le fait que la version puisse être expédiée ou non est une question plus large que celle de savoir si les tests sont terminés, car la documentation, la préparation du support et la configuration de facturation y contribuent aussi. Le modèle d’exigences de version couvre cela.

Variantes de plan de test

La structure reste, et l’accent se déplace.

Plans de test Agile ou par sprint. Généralement beaucoup plus courts, souvent une seule page, et fréquemment intégrés à la définition du « done ». L’argument des critères de sortie s’applique inchangé et compte davantage, car la décision se répète à chaque sprint.

Plans de test d’acceptation utilisateur. Le critère de sortie est une personne qui signe quelque chose ; précisez donc ce qu’elle confirme avoir fait personnellement. Une signature sur un document que personne n’a lu est le contrôle le plus faible dans l’usage courant.

Plans de test de performance et de charge. Les seuils sont naturellement numériques, ce qui rend ces plans les plus faciles à rédiger avec des critères applicables. La difficulté se déplace vers la capacité de l’environnement à générer une charge représentative.

Environnements réglementés et validés. Dans les contextes pharmaceutiques, dispositifs médicaux et similaires, des exigences définies s’appliquent à la documentation de test, à la traçabilité et à l’approbation, et le plan fait partie d’un dossier de preuves qui peut être inspecté des années plus tard. Construisez selon la norme applicable avec des entrées qualifiées, car rien sur cette page ne remplace cela.

Matériel et systèmes intégrés. Les plans de test doivent couvrir les configurations physiques et les conditions environnementales, et la section « environnement » devient généralement la partie la plus longue du document.

Ce qu’un modèle de plan de test gratuit ne peut pas corriger

Une date qui ne peut pas bouger. Si la version doit sortir quoi qu’il arrive, le plan documente ce qui a été ignoré plutôt que de l’empêcher. C’est parfois une décision commerciale légitime et elle devrait être indiquée, plutôt que déguisée en critère « passé ».

Un environnement qui ne peut pas révéler le défaut. Aucun téléchargement gratuit de modèle de plan de test gratuit ne vous donnera des volumes de données de production ou une concurrence réelle.

Une sévérité attribuée par la partie intéressée. La manière la plus courante de contourner les critères de sortie, et c’est un choix de gouvernance plutôt qu’un choix de documentation.

Une fenêtre qui n’a jamais été réaliste. Faire le calcul dans le plan rend au moins le manque visible tant qu’il reste du temps pour changer quelque chose.

Montrer que les tests ont eu lieu

Les critères de sortie dépendent de preuves, et dans la plupart des organisations, les preuves sont une colonne d’état.

La suite de régression a été exécutée. Quelqu’un a coché les cas. Le fait que chaque cas ait été exécuté comme écrit, et ce qui a réellement été observé, n’est consigné nulle part ; cela signifie qu’un critère indiquant « 100 % exécuté » repose sur une affirmation plutôt que sur un enregistrement. Après un incident, c’est cette affirmation qui est examinée, et elle ne peut généralement pas être étayée dans un sens ou dans l’autre.

Trupeer AI produit l’enregistrement comme sous-produit. Enregistrer une exécution de test génère une visite guidée écrite avec des captures d’écran déjà capturées et placées, aux côtés de la vidéo, dans votre propre branding. Ce qui a été observé à chaque étape existe plutôt que d’être affirmé, ce dont un vérificateur a besoin pour signer un critère honnêtement.

Consignez-le. Mettez-le en marque. Traduisez-le. Trupeer it.

Deux points suivent. Lorsque les tests sont réalisés par une équipe externalisée ou offshore, la preuve de ce qui a réellement été fait vaut plus qu’un rapport d’état, et un enregistrement est la forme la moins coûteuse. Et un enregistrement d’un testeur expérimenté qui parcourt un scénario complexe, c’est ainsi qu’un nouveau testeur apprend à quoi ressemble une vérification correctement menée : une habitude qu’aucun cas de test écrit ne transmet.

Le contenu se trouve dans votre base de connaissances et sert aussi de formation. La cohérence entre vos documents dépend du fait de définir le brand kit une seule fois, et la configuration est couverte dans le guide de configuration du modèle de document.

Questions fréquentes

Existe-t-il une version Word gratuite du modèle de plan de test ?

Word convient au plan lui-même, car la plupart de celui-ci est un texte qui fait l’objet d’une relecture et d’un accord, et parce qu’il nécessite généralement une approbation. Un fichier Word de modèle de plan de test est le bon format de travail.

Placez le tableau des critères de sortie sur la première page. Chaque modèle les place près de la fin, c’est là qu’ils sont lus en dernier lors de la rédaction et qu’ils reçoivent le moins d’attention, et c’est la seule partie du document qui sera utilisée sous pression.

Existe-t-il une version Word simple du modèle de plan de test ?

Oui, et pour une petite version ou un seul sprint, un fichier Word simple de modèle de plan de test d’une ou deux pages convient parfaitement.

Supprimez les sections « approche » et « ressources » avant de supprimer les critères de sortie. Un plan d’une page avec des critères numériques, un vérificateur nommé et une autorité de levée vaut plus qu’un plan de quinze pages sans eux.

Existe-t-il une version Excel gratuite du modèle de plan de test ?

Excel convient aux parties d’un plan de test qui sont tabulaires : le calendrier, la matrice de couverture, l’allocation des ressources et le tableau des critères de sortie. Un fichier Excel de modèle de plan de test gère bien ces éléments.

Les sections « périmètre », « approche » et « risques » sont du texte et doivent figurer dans un document. Diviser un plan en deux fichiers est acceptable à condition qu’un fichier fasse référence à l’autre et qu’il n’y ait qu’une seule version approuvée.

Existe-t-il un modèle de plan de test gratuit au format PDF ?

Le PDF est la copie approuvée jointe au dossier de version. Exportez une fois un modèle de plan de test gratuit au format PDF, une fois approuvé, avec la version et la date, puis conservez-le à côté des résultats et de tout registre de levée.

Ce pack est ce qui est examiné si quelque chose tourne mal plus tard, et le registre de levée est la partie que les gens regrettent de ne pas avoir. Un plan sans trace de ce qui a été levé oblige tout le monde à reconstituer une réunion à partir de la mémoire.

Où puis-je trouver un exemple de document de plan de test au format PDF ?

Les universités, les marchés publics du secteur public et les industries réglementées publient des exemples réels, et un exemple de document de plan de test au format PDF provenant de ces sources est plus utile qu’un modèle commercial, car il a été rédigé avec de vraies contraintes et souvent relu par quelqu’un ayant une autorité.

Lisez les critères de sortie et la section « hors périmètre ». Ces deux éléments montrent si le plan est un contrôle ou une formalité, et ce sont les sections qui diffèrent le plus entre les organisations qui expédient de manière fiable et celles qui ne le font pas.

Existe-t-il un téléchargement gratuit de modèle de plan de test qui vaille le coup ?

La liste des sections est stable depuis des décennies, donc un téléchargement gratuit de modèle de plan de test ne vous fait gagner que peu de choses et chaque version offre à peu près la même structure.

Évaluez-les selon une seule question. Les critères de sortie prévoient-ils un seuil, un vérificateur et une autorité de levée ? Aucun ne le fait. Ajouter ces trois colonnes prend deux minutes et fait la différence entre un plan qui décide quelque chose et un plan qui décrit une intention.

Que doivent dire concrètement les critères de sortie ?

Des nombres, des vérificateurs et une autorité de levée. Pas « suite de régression passée », mais « 100 % des cas priorité un exécutés et passés, vérifiés par le responsable QA, non levables ».

Le test consiste à savoir si quelqu’un pourrait satisfaire le critère sans faire le travail et sans mentir. Si un défaut peut être reclassé, un pourcentage peut être lu comme un taux de réussite, ou une signature peut être donnée par quelqu’un qui n’a rien vérifié : le critère a une voie pour être contourné et nécessite une autre clause.

Qui doit rédiger le plan de test ?

La personne qui pilote les tests, avec des critères de sortie approuvés par quelqu’un qui ne détient pas la date de sortie. Cette séparation est le point clé, et c’est pourquoi les plans rédigés entièrement au sein d’une équipe de livraison ont tendance à avoir des critères « souples ».

Faites lire spécifiquement les critères de sortie au responsable métier, car l’un d’eux dépend généralement de sa signature et il/elle doit savoir à l’avance ce qu’il/elle confirmera avoir fait personnellement.