Tests des systèmes numériques et mise en service

Un ordinateur peut démarrer normalement et échouer malgré tout à la première tâche dont son utilisateur a besoin. Les tests soumettent un système configuré à des actions connues, puis comparent ce qui se produit à ce qui devrait se produire. Le système peut être un ordinateur portable, une imprimante, une configuration de comptes ou une application utilisée par une équipe.

Tests et assurance qualité

L’assurance qualité améliore la façon dont le travail est réalisé afin de prévenir les problèmes. Une liste de contrôle de configuration standard, un socle de sécurité convenu et une revue du plan de test sont des activités d’assurance qualité. Le test examine le système particulier produit par ce processus. Il relève du contrôle qualité : il trouve des défauts et fournit des preuves pour la décision de mise en service.

Les tests aident à éviter les pertes de travail, les tâches bloquées et les incidents de sécurité. Ils donnent aussi au responsable du système une base pour l’accepter. Un dossier qui s’ouvre pour le technicien mais refuse l’accès au compte de l’utilisateur est un problème à découvrir avant le premier jour de travail de celui-ci.

Suivre un problème, de l’erreur à la défaillance

Ces termes décrivent différentes parties d’une même histoire :

Un test peut révéler la défaillance. Le diagnostic suit ensuite la méthode de dépannage pour en établir la cause ; le résultat du test ne prouve pas à lui seul quel paramètre est incorrect.

La vérification contrôle les spécifications : le système a-t-il été configuré comme demandé ? La validation contrôle le besoin : les personnes peuvent-elles effectuer leur travail réel ? Un ordinateur portable peut correspondre à sa liste de contrôle de configuration tout en ne possédant pas une application nécessaire à l’utilisateur. C’est pourquoi les tâches des utilisateurs et les règles internes contribuent toutes deux à définir les tests.

Choisir le niveau et le type

Le niveau d’un test décrit ce qui est examiné. Les développeurs testent les composants logiciels individuels et leur intégration. Les techniciens d’assistance testent principalement l’ensemble du système configuré. Les tests d’intégration système vérifient les connexions à d’autres systèmes, comme le stockage en nuage ou la messagerie. Le test d’acceptation permet aux utilisateurs ou aux responsables de vérifier l’aptitude à l’utilisation.

Le type d’un test décrit la qualité examinée. Le test fonctionnel vérifie ce que fait le système. Le test non fonctionnel vérifie les performances, l’utilisabilité, l’accessibilité, la sécurité, la fiabilité et la compatibilité. Ce sont des dimensions distinctes : un test d’acceptation peut examiner les performances aussi bien que les fonctionnalités.

Le test boîte noire part des exigences sans examiner la structure interne. Le test boîte blanche utilise la connaissance du code ou de la logique de configuration. La plupart des contrôles des tâches en assistance sont des tests boîte noire.

Les tests ne peuvent pas couvrir toutes les combinaisons possibles de comptes, de données et de conditions. Donne la priorité aux domaines où une défaillance est probable ou dommageable, et teste assez tôt pour corriger les problèmes avant que les utilisateurs dépendent du système. Une exécution sans problème établit que ces tests n’ont trouvé aucun défaut. Elle ne prouve pas que le système n’en comporte aucun. Inclus les exigences des politiques de sécurité, d’accessibilité et de protection des données, même si le demandeur ne les a pas mentionnées.

Les demandes mélangent souvent une tâche, une solution préférée et une attente vague. Avant les tests, sépare ces éléments et conviens de ce qui constituera une réussite. Une exigence claire permet à deux testeurs de prendre la même décision de réussite ou d’échec.

Partir de la tâche de l’utilisateur

Une exigence utilisateur exprime un besoin en langage courant : « J’ai besoin de numériser des factures dans le dossier des finances. » Les exigences système associées déterminent ce qui doit permettre cette tâche : un pilote de scanner adapté, les paramètres de numérisation vers un dossier, une autorisation d’écriture et l’accès au serveur de fichiers.

Une exigence fonctionnelle indique ce que fait le système, par exemple imprimer sur une imprimante attribuée. Une exigence non fonctionnelle indique dans quelle mesure il fonctionne bien ou quelles contraintes s’appliquent, comme un délai maximal de connexion ou un accès restreint aux dossiers financiers. Les deux nécessitent des preuves.

« Installe ce navigateur » peut être une solution proposée pour « Ouvrir le portail du fournisseur ». Installer le navigateur vérifie une action. Accomplir la tâche sur le portail valide le besoin de l’utilisateur.

Rendre la réussite observable

Un critère de réussite, aussi appelé critère d’acceptation, donne une condition claire pour réussir. Remplace « rapide », « facile » ou « sécurisé » par une mesure convenue ou un résultat visible. Précise l’action, les conditions, le seuil et l’unité lorsque c’est pertinent.

Pour un PC d’accueil, « rapide et sécurisé » peut devenir :

1. Entre la mise sous tension et l’affichage d’un bureau utilisable, il s’écoule au maximum 60 secondes lors de chacun des trois tests.
2. L’application de réservation s’ouvre en 5 secondes au maximum.
3. L’écran se verrouille après 5 minutes sans activité.
4. L’agent d’accueil utilise un compte standard et ne peut pas installer de programmes nécessitant des droits d’administrateur.
5. Le disque système est chiffré.

Les délais sont des exigences convenues, pas des normes universelles pour tous les ordinateurs. Demande au demandeur de les confirmer avant les tests. Sinon, un testeur pourrait choisir un seuil facile à atteindre après avoir vu les résultats.

Repérer les exigences moins visibles

Demande qui utilisera le système, quelles tâches comptent, quels appareils et applications ces personnes utilisent et de quels paramètres d’accessibilité ou technologies d’assistance elles ont besoin. Ajoute les exigences issues des règles internes. Une tâche de connexion peut dépendre du réseau, d’un service d’identité et de l’authentification multifacteur ; une application peut nécessiter un système d’exploitation particulier, une connexion à une base de données ou un serveur de licences.

La compatibilité signifie que ces combinaisons requises fonctionnent ensemble. Si le personnel utilise deux navigateurs, n’en tester qu’un laisse une partie de l’exigence sans vérification. Consigne les dépendances pour que l’environnement de test puisse les inclure.

Relier les priorités aux tests

Les priorités de la méthode MoSCoW distinguent indispensable, souhaitable, facultatif et exclu pour cette fois. L’échec d’une exigence indispensable bloque normalement la mise en service. L’échec d’une exigence facultative peut devenir un problème connu accepté. La priorité aide à choisir l’ordre et le niveau de détail des tests, mais ne transforme pas un échec en réussite.

Construis un tableau de traçabilité avec l’identifiant de l’exigence, le critère de réussite, les identifiants des cas de test et le résultat. Une ligne sans test révèle une lacune de couverture. Lorsqu’une exigence change, mets à jour ses tests et le tableau ensemble. Les exigences vérifiables par des tests sont confirmées avec le demandeur ; elles ne se limitent pas aux tâches les plus faciles à contrôler.

Un environnement de test te donne un espace pour modifier des paramètres, répéter des actions et réinitialiser des données sans interrompre le travail réel. Il doit aussi ressembler suffisamment à la cible pour que les résultats t’apprennent quelque chose d’utile.

Adapter l’environnement à l’objectif

L’environnement de production contient le travail et les données réels. Les environnements hors production répondent à différents besoins :

Une machine virtuelle peut exécuter un système d’exploitation de test sur un ordinateur physique existant. Un instantané capture son état avant une modification. Le retour à cet instantané permet à un collègue de répéter le test à partir du même point de départ. Consigne cet état initial : un test qui dépend d’une modification antérieure inconnue est difficile à reproduire.

Obtenir des résultats représentatifs

Compare la configuration de test aux appareils prévus. Vérifie la version et le build du système d’exploitation, les applications, les stratégies, la capacité matérielle, l’accès réseau et les autorisations. Une application qui fonctionne bien avec 32 Go de mémoire peut être lente sur l’ordinateur portable de l’utilisateur doté de 8 Go. Un compte de test avec des droits d’administrateur peut masquer un problème d’accès pour un utilisateur standard.

La représentativité dépend de ce que le test cherche à établir. Une machine virtuelle peut vérifier de nombreux paramètres, mais un résultat concernant une imprimante physique ou un ordinateur portable précis nécessite toujours l’appareil concerné. Note les différences entre le test et la production afin que le rapport d’aptitude à la mise en service puisse expliquer ce qui reste à confirmer.

Préparer les comptes, les données et une méthode de retour à l’état initial

Utilise des données synthétiques, comme des clients inventés et des exemples de factures, ou des données correctement anonymisées. Lorsque des données personnelles réelles sont nécessaires, respecte la politique applicable : utilise le minimum, limite l’accès et supprime-les à la fin des tests. Les données de formation doivent être suffisamment réalistes pour permettre la tâche sans exposer les dossiers d’un client.

Identifie clairement les appareils, comptes et serveurs de test. Vérifie la cible du script avant chaque exécution. Un test bien rédigé peut tout de même causer des dommages s’il envoie des messages à de vrais clients ou supprime des données sur un serveur de production. Des identifiants et des destinations de test distincts aident à éviter cette erreur.

Confirme les critères d’entrée avant de commencer : la configuration prévue est installée, les comptes et les appareils sont disponibles, les données de test sont chargées, les outils fonctionnent et la référence de performance a été enregistrée. Conserve avec les résultats le modèle de l’appareil, le build du système d’exploitation, les versions des applications et les détails du réseau. Ces informations décrivent les conditions dans lesquelles une réussite a été obtenue.

Certains contrôles finaux doivent être exécutés sur le système réel transféré. Conviens d’un créneau, conserve une sauvegarde ou une méthode d’annulation lorsqu’une modification est en jeu, et privilégie les contrôles en lecture seule. Un contrôle final de l’appareil confirme l’état de ce qui est livré ; il ne transforme pas une machine en production en lieu sûr pour des expériences perturbatrices.

Un plan de test transforme un ensemble de contrôles en un travail convenu. Il définit l’objectif, les limites et les responsabilités avant que les résultats soient connus, afin que les tests ne dépendent pas de la personne disponible ce jour-là.

Préciser ce que comprend le travail

Indique l’objectif ainsi que les appareils, comptes, applications et connexions testés. Répertorie ce qui est inclus dans le périmètre et ce qui en est exclu. Inclus les types de test, l’environnement, les données, les outils, les personnes, le calendrier, les risques et la méthode de compte rendu. Le demandeur doit pouvoir voir comment le plan répond aux exigences.

Un tableau de plan pratique peut indiquer chaque test, son objectif, les données, le résultat attendu et un espace pour le résultat réel. Les instructions détaillées et reproductibles figurent dans les cas de test liés. Le plan coordonne l’ensemble de l’activité ; un cas de test décrit un contrôle.

Convenir du début et de la fin

Les critères d’entrée indiquent ce qui doit être prêt avant le début des tests. Pour un lot d’ordinateurs portables, ils peuvent exiger la configuration standard et des comptes de test sur les 12 appareils.

Les critères de sortie indiquent les conditions à remplir pour considérer les tests comme terminés. Par exemple : « Tous les tests prévus ont été exécutés, toutes les exigences indispensables sont satisfaites et aucun défaut de gravité critique ou élevée n’est ouvert. » Ils permettent au responsable du système de juger les résultats de manière cohérente. Une échéance est une contrainte de calendrier, pas une preuve que ces conditions ont été remplies.

Les tests bloqués et non exécutés restent visibles lors de l’examen des critères de sortie. Si un service requis est indisponible, note cette lacune et son effet sur la décision. Ne marque pas l’exigence comme satisfaite parce que le technicien a manqué de temps.

Consacrer les efforts aux défaillances importantes

Le test basé sur les risques accorde davantage d’attention aux défaillances probables ou dommageables. La connexion, l’accès aux données métier, l’application principale et les paramètres de sécurité méritent généralement des contrôles précoces. Une erreur de fond d’écran peut faire l’objet d’un contrôle rapide, car son impact est différent.

Pour 12 ordinateurs portables commerciaux, un plan pourrait inclure la connexion, la messagerie, la base de données clients, le VPN, l’impression, un partage d’équipe, le chiffrement, les mises à jour et l’agrandissement pour un utilisateur malvoyant. Le code interne de la base de données est exclu de ce test d’assistance. Commence sur un réseau de test distinct, puis effectue les contrôles finaux avec les comptes appropriés.

Si les configurations sont identiques, teste deux appareils en profondeur et utilise une liste de contrôle d’aptitude à la mise en service sur les 12. Tester par échantillonnage le comportement commun fait gagner du temps, mais les caractéristiques propres à chaque appareil nécessitent toujours des contrôles individuels. L’état du chiffrement, les mises à jour, l’état de santé de la batterie et le compte de l’utilisateur peuvent différer entre des ordinateurs portables identiques par ailleurs. Les critères de sortie exigeant que les exigences indispensables soient satisfaites sur les 12 s’appliquent toujours aux 12.

Maintenir le plan à jour lors des changements

Attribue des rôles clairs : qui prépare les comptes, exécute les cas de test, consigne les défauts et accepte le système. Réserve du temps pour les corrections et les nouveaux tests. Repère les risques, comme du matériel de test indisponible ou une dépendance inaccessible, et conviens de la manière de les traiter.

Lorsque le demandeur modifie une exigence, révise ensemble son critère de réussite, ses cas de test, le calendrier et sa ligne de traçabilité. Conserver l’ancien plan crée un écart entre le système attendu et celui que décrivent réellement les preuves.

Un collègue doit pouvoir exécuter un cas de test à partir de ses instructions écrites et obtenir un résultat comparable. Cela suppose un état initial connu, des actions claires et un résultat attendu choisi avant l’exécution du test.

Rédiger un contrôle reproductible

Inclus un identifiant et un titre, l’exigence liée, les préconditions, les étapes numérotées, les données de test et le résultat attendu. Pendant l’exécution, ajoute le résultat observé, le statut, le nom du testeur et la date. « Ça marche » est trop vague. « Le compte est affiché comme verrouillé et un mot de passe correct est refusé jusqu’au déverrouillage » décrit un comportement observable.

Les préconditions empêchent les tests précédents de modifier le sens des suivants. Un test de verrouillage ne peut pas compter cinq échecs de façon fiable si le compte enregistre déjà trois tentatives échouées.

Examiner le verrouillage d’un compte

Pour une exigence de verrouillage après cinq connexions échouées, fixe le seuil à cinq. Commence avec un compte de test actif et non verrouillé, dont le compteur de tentatives échouées est à zéro. Effectue ces étapes sans pause assez longue pour réinitialiser le compteur :

1. Saisis quatre fois un mot de passe incorrect.
2. Vérifie que le compte est toujours actif.
3. Saisis une cinquième fois un mot de passe incorrect.
4. Essaie le mot de passe correct.

Le résultat attendu après quatre échecs est l’absence de verrouillage. Le cinquième provoque le verrouillage et le mot de passe correct est refusé jusqu’à ce qu’un administrateur déverrouille le compte ou que sa période de verrouillage prenne fin. Réinitialise le compte avant une nouvelle exécution afin de retrouver les mêmes conditions initiales.

Choisir des données qui peuvent révéler une erreur

Les tests positifs vérifient les actions autorisées et les données acceptables. Les tests négatifs vérifient que les actions interdites et les données inacceptables sont rejetées sans danger. Un test négatif réussit lorsque le rejet requis se produit ; « rejeté » ne signifie pas automatiquement « échoué ».

Certains cours regroupent les données invalides et erronées. Dans un plan de test, l’essentiel est que les cas choisis vérifient à la fois les violations de règles et les données inadaptées.

Un minimum de 12 inclut exactement 12. Tester uniquement 11 et 15 pourrait laisser passer un défaut qui exige à tort plus de 12. À la borne supérieure, 64 doit être accepté et 65 rejeté. Précise les autres conditions du mot de passe afin que le contrôle de longueur ne soit pas confondu avec une autre règle.

Vérifier qu’un résultat a un sens

Les résultats étonnamment bons doivent aussi être vérifiés. Un fichier de 2 Go contient 16 gigabits : une liaison à 1 Gbit/s a donc besoin d’au moins 16 secondes pour le transmettre, sans compter les données supplémentaires de transmission. Une copie annoncée en 0,1 seconde suggère que la mesure ne représentait pas ce transfert réseau. Conserve l’observation, examine la méthode et consulte un expert du domaine si nécessaire. Mets à jour les cas lorsque les exigences et les configurations changent ; répéter uniquement les parcours attendus finit par ne plus révéler de nouveaux problèmes.

Les tests utilisent de l’électricité, du matériel et du temps de travail. Des tests efficaces maintiennent le niveau d’assurance requis tout en évitant les ressources inactives, les reconstructions inutiles et les travaux répétés qui n’apportent aucune preuve supplémentaire.

Calculer l’énergie à partir de la puissance et du temps

La puissance est le débit de consommation d’énergie. Convertis les watts en kilowatts, puis multiplie par les heures de fonctionnement :

Un serveur consommant 120 W utilise une puissance de 0,12 kW. Un fonctionnement continu pendant 30 jours donne 720 heures et consomme 86,4 kWh. Un fonctionnement limité à dix jours de test de 8 heures donne 80 heures et consomme 9,6 kWh. La différence est de 76,8 kWh, soit une économie d’environ 89 %. Ces chiffres supposent la puissance consommée constante indiquée ; des mesures réelles permettent d’établir la consommation effective d’un appareil.

Réutiliser les configurations et arrêter les ressources inactives

Réutilise les appareils de test, les machines virtuelles et les instantanés lorsqu’ils répondent aux exigences des tests. Automatise les contrôles répétitifs et conserve les résultats au format numérique. Les configurations identiques peuvent faire l’objet de tests approfondis sur un échantillon, tandis que chaque appareil reçoit toujours les contrôles individuels d’aptitude à la mise en service dont il a besoin.

Après les tests, arrête les machines virtuelles de test et supprime les ressources en nuage inutilisées. Vérifie l’état réel des ressources sur la plateforme : sur Azure, un arrêt depuis le système d’exploitation peut laisser une machine virtuelle allouée et les frais de calcul se poursuivre. Sa désallocation met fin à ces frais de calcul, tandis que les disques conservés continuent de générer des frais de stockage. Suis les procédures d’arrêt et de suppression documentées par la plateforme et vérifie ce qui reste.

Tester les paramètres d’efficacité au regard du travail réel

Les programmes de démarrage et les services en arrière-plan inutiles consomment du temps processeur et de la mémoire. Mesure l’utilisation des ressources et le temps de réponse avant et après une modification de configuration, dans des conditions comparables. Attribue à une machine virtuelle la mémoire et la capacité de processeur dont elle a besoin sans prendre de capacité inutilisée à l’hôte.

Les paramètres de mise en veille et d’extinction de l’écran réduisent la consommation d’énergie pendant l’inactivité, mais leur délai doit convenir à la tâche. Un écran d’information à l’accueil peut devoir rester visible toute la journée. Un appareil programmé pour recevoir des mises à jour pendant la nuit doit se réveiller ou rester disponible pendant cette fenêtre. Un paramètre d’économie d’énergie ne convient pas s’il empêche une tâche indispensable.

Ne supprime pas un service en arrière-plan requis simplement parce qu’il apparaît dans un outil de surveillance des ressources. Le test vérifie la configuration convenue et son effet ; un échec est consigné pour investigation. L’efficacité et les performances sont mesurées au regard des mêmes exigences utilisateur et règles internes que les autres paramètres.

Utiliser le matériel pendant sa durée de vie utile

Les tests peuvent montrer qu’un appareil ancien répond encore aux exigences, ce qui retarde son remplacement et le besoin des matières nécessaires à sa fabrication. Réutiliser le matériel de test réduit aussi les déchets. Les économies d’énergie dépendent de l’appareil et de sa charge de travail : la fabrication représente une grande part de l’empreinte de nombreux ordinateurs portables et téléphones, tandis qu’un serveur peu efficace peut consommer assez d’électricité en fonctionnement pour que son remplacement soit préférable.

Lorsque le matériel atteint la fin de sa durée de vie utile, organise l’effacement sécurisé des données et son recyclage par une filière agréée. La réutilisation n’est utile que si l’appareil reste adapté à sa prochaine tâche et si ses données précédentes sont protégées.

Un test fonctionnel suit une tâche jusqu’à son résultat utile. Ouvrir un programme n’est que le début si l’utilisateur doit s’en servir pour modifier, enregistrer, envoyer ou imprimer son travail.

Suivre la tâche complète

Pars des exigences fonctionnelles et répertorie les actions que l’utilisateur doit accomplir. Les contrôles d’assistance courants comprennent la connexion ; l’ouverture des applications requises ; la modification et l’enregistrement de fichiers partagés ; la messagerie interne et externe ; l’impression ; l’accès au Wi-Fi et au VPN ; la numérisation ; les sites web requis ; et un appel avec la caméra et le casque-micro.

Pour chaque tâche, détermine la preuve finale. Une boîte de dialogue d’impression ne prouve pas que l’imprimante attribuée a produit une page lisible. Un message d’enregistrement constitue une preuve plus solide lorsque le fichier peut être fermé, rouvert et vérifié pour confirmer son contenu attendu.

Utiliser le bon compte

Effectue les tâches destinées à l’utilisateur avec son compte ou avec un compte de test appartenant aux mêmes groupes. Un administrateur peut accéder à des fichiers ou modifier des paramètres qu’un utilisateur standard ne peut pas atteindre ou modifier. Tester uniquement en tant qu’administrateur peut masquer précisément le problème d’autorisation que l’utilisateur rencontrera.

Pour un partage Sales, connecte-toi avec un compte de test Sales. Ouvre le partage, crée « Quote-test.docx », enregistre-le, ferme-le et ouvre-le à nouveau. Vérifie son contenu. Essaie ensuite d’ouvrir le partage HR avec ce même compte. Si le personnel commercial ne doit pas accéder à HR, le résultat attendu est « Accès refusé ». Consigne séparément les résultats positif et négatif.

Un technicien peut avoir besoin d’un outil autorisé exécuté avec élévation de privilèges pour examiner un paramètre protégé. Ce contrôle est différent de celui qui prouve que l’utilisateur peut effectuer une tâche. Consigne le compte et le niveau de privilèges dans chaque résultat.

Choisir un contrôle rapide ou un test détaillé

Un test fumigatoire est un contrôle court et superficiel des fonctions essentielles : démarrage, connexion, connexion réseau et application principale. Exécute-le en premier pour repérer une configuration qui n’est pas prête pour des tests plus approfondis. Si la connexion échoue, de nombreuses tâches ultérieures ne peuvent pas être tentées utilement.

La réussite du test fumigatoire n’établit pas que toutes les tâches fonctionnent. Poursuis avec les cas de test de bout en bout prévus, y compris les actions moins fréquentes mais requises. Une application qui s’ouvre peut tout de même échouer à enregistrer un rapport ou à se connecter à un service.

Tester à nouveau les corrections et les comportements associés

Le test de confirmation répète le test échoué après une correction. Il détermine si le problème initial a disparu. Le test de non-régression répète les contrôles qui avaient réussi auparavant afin de repérer les effets néfastes de la modification.

Après la mise à jour d’un pilote d’imprimante, répète d’abord le cas d’impression qui a échoué. Vérifie ensuite l’impression depuis les autres applications essentielles et la numérisation lorsque le même paquet de pilotes pourrait l’affecter. Conserve l’échec initial et ajoute les nouveaux résultats, afin que le compte rendu montre à la fois le défaut et la preuve de sa correction.

Vérifier les combinaisons requises

Le test de compatibilité couvre les systèmes d’exploitation, navigateurs, appareils et formats de fichiers dont les utilisateurs ont réellement besoin. Un portail qui fonctionne dans un navigateur ne confirme pas le fonctionnement du second navigateur pris en charge. Consigne les versions et les combinaisons testées ; sinon, affirmer que « le portail fonctionne » masque une partie du périmètre. Même après une petite modification, choisis des tests de non-régression pour les fonctions qu’elle pourrait affecter.

Le test de performance remplace « ça semble lent » par des mesures dans des conditions connues. Le test de stabilité cherche à savoir si un comportement acceptable se maintient dans le temps : une exécution rapide et réussie ne constitue donc qu’une partie des preuves.

Adapter l’indicateur à l’exigence

Le temps de réponse mesure l’attente entre une action et son résultat, en secondes ou millisecondes. Le débit mesure le travail par unité de temps, par exemple en pages par minute ou en Mbit/s. L’utilisation des ressources comprend le pourcentage d’utilisation du processeur, l’utilisation de la mémoire, l’activité du disque et l’utilisation du réseau. La latence réseau est le délai en millisecondes ; la perte de paquets est le pourcentage de requêtes sans réponse.

Conserve une référence mesurée dans des conditions normales. Compare les résultats ultérieurs à cette référence et aux seuils convenus. Une mesure de 70 % d’utilisation du processeur a peu de sens sans connaître la charge de travail et le comportement normal de ce système.

Choisir des conditions réalistes

Une exécution avec un seul utilisateur sur un réseau peu sollicité ne peut pas établir les performances pendant une matinée chargée. Un test d’endurance peut révéler une utilisation de la mémoire qui continue d’augmenter ou un ralentissement qui met des heures à apparaître. Répète les mesures avec la même méthode et consigne les conditions, comme un démarrage à froid, les mises à jour en arrière-plan et le mode de gestion de l’alimentation.

Examiner d’autres indicateurs que la moyenne

Pour des temps de connexion de 4,2 ; 3,8 ; 4,0 ; 9,6 et 4,1 secondes, le total est de 25,7 secondes. La division par cinq donne une moyenne de 5,14 secondes. Les valeurs ordonnées sont 3,8 ; 4,0 ; 4,1 ; 4,2 et 9,6 : la médiane est donc de 4,1 secondes et le maximum de 9,6 secondes.

Le critère « médiane d’au maximum 5 secondes et aucun temps de connexion supérieur à 10 secondes » est satisfait. L’exécution lente porte la moyenne au-dessus de 5 secondes, mais le critère ne précise pas la moyenne. Conserve l’observation lente pour investigation ; ne la supprime pas simplement parce qu’elle est inhabituelle.

Un critère en pourcentage nécessite aussi son nombre correspondant. « 95 % de 20 chargements de page en moins de 2 secondes » exige 19 chargements conformes. Un chargement plus lent est autorisé ; deux ne le sont pas. Une réponse perdue sur 20 requêtes ping représente 5 % de perte. « Moins de 2 secondes » exclut exactement 2 secondes, tandis que « au maximum 2 secondes » les inclut.

Consigner un échec avant de l’examiner

Utilise le Gestionnaire des tâches, le Moniteur de ressources ou l’Analyseur de performances sous Windows ; le Moniteur d’activité sous macOS ; ou top, htop et free -h sous Linux. Un chronomètre mesure l’attente de l’utilisateur, tandis que ping aide à mesurer la latence et la perte. Conserve les unités et la méthode avec chaque résultat.

Une mémoire insuffisante, les programmes de démarrage, un pilote, le mode de gestion de l’alimentation, la capacité matérielle, des défauts logiciels et des services externes peuvent tous affecter les performances. Le non-respect d’un seuil indique un problème à examiner, pas sa cause. Après correction, mesure à nouveau dans des conditions comparables pour que la comparaison avant-après ait un sens.

Un système peut remplir ses fonctions techniques tout en rendant les tâches quotidiennes difficiles ou impossibles pour certains utilisateurs. Les contrôles d’utilisabilité et d’accessibilité examinent la tâche du point de vue de l’utilisateur visé, y compris les paramètres et les technologies d’assistance qu’il utilise.

Observer la tâche sans prendre le relais

L’utilisabilité concerne l’efficacité, l’efficience et la satisfaction : les personnes peuvent-elles atteindre leurs objectifs avec un effort et une expérience acceptables ? Parcours les tâches essentielles, note les étapes et le temps nécessaire, et repère les libellés déroutants ou les erreurs peu claires. Observe ensuite un utilisateur représentatif qui essaie sans l’aider. Une aide peut masquer le moment où l’interface cesse d’avoir un sens pour lui.

Une application épinglée ou un lecteur réseau connecté peut raccourcir une tâche quotidienne. Vérifie que tout ajustement satisfait toujours aux exigences d’accès et de sécurité.

Vérifier l’accès pour les personnes en situation de handicap

L’accessibilité concerne la possibilité pour les personnes en situation de handicap visuel, auditif, moteur ou cognitif de percevoir, d’utiliser et de comprendre le système. Les lecteurs d’écran, les loupes, la commande vocale et les contacteurs sont des exemples de technologies d’assistance.

Les WCAG 2.2 regroupent l’accessibilité du web autour de quatre principes : perceptible, utilisable, compréhensible et robuste. Leurs critères ont les niveaux A, AA et AAA. De nombreuses organisations utilisent le niveau AA, qui inclut aussi les exigences du niveau A. Les WCAG sont rédigées pour les contenus web et servent aussi à guider le travail sur les applications et les documents.

Les contrôles pratiques comprennent :

• Effectuer la tâche avec les commandes du clavier et garder le focus visible.
• Utiliser un lecteur d’écran pour vérifier que les noms des boutons, des champs et des titres ont un sens.
• Agrandir le texte à 200 % et vérifier qu’aucun contenu ni aucune fonction ne disparaît.
• Confirmer que le sens ne dépend pas uniquement de la couleur et que les vidéos comportent des sous-titres.
• Vérifier la taille des cibles du pointeur. Les WCAG 2.2 au niveau AA fixent un minimum de 24 par 24 pixels CSS, avec des exceptions définies.

Interpréter précisément le contraste

Pour le texte normal, le rapport de contraste minimal au niveau AA est de 4,5:1. Pour le texte de grande taille, il est de 3:1. Le texte de grande taille correspond à au moins 18 points, ou 14 points en gras. Ces rapports entre le premier plan et l’arrière-plan vont de 1:1 à 21:1.

Un outil de vérification du contraste donne environ 4,54:1 pour #767676 sur blanc, ce qui satisfait au seuil pour le texte normal. #777777 donne environ 4,48:1 : cette couleur ne satisfait pas au critère pour le texte normal, mais le satisfait pour le texte de grande taille. N’arrondis pas une valeur inférieure au seuil vers le haut pour la faire passer.

Tester la configuration réelle de l’utilisateur

Configure les options nécessaires : agrandissement, mise à l’échelle, thèmes contrastés, taille du pointeur, lecteur d’écran, sous-titres en direct, touches rémanentes ou dictée. Confirme que les paramètres restent actifs après une déconnexion et un redémarrage, puis effectue la tâche métier avec ces paramètres. Un écran qui paraît correct avec la mise à l’échelle du technicien peut perdre une commande avec le réglage à 200 % de l’utilisateur.

Les outils automatisés trouvent des problèmes comme les alternatives textuelles manquantes et les contrastes insuffisants. Ils ne peuvent pas juger entièrement si les descriptions ont un sens, si l’ordre de lecture est cohérent ou si une tâche est pratique à accomplir. Ajoute des contrôles manuels au clavier et au lecteur d’écran et, si possible, fais participer des utilisateurs avec leurs propres technologies d’assistance.

Les contrôles de sécurité confirment que les protections requises sont présentes et se comportent correctement. Une action bloquée peut constituer un résultat réussi : un compte Sales doit pouvoir utiliser les fichiers Sales tout en se voyant refuser l’accès aux dossiers RH à accès restreint.

Savoir ce qui est protégé

La confidentialité limite les personnes qui peuvent voir les données. L’intégrité protège les données et les paramètres contre les modifications inappropriées. La disponibilité maintient le système utilisable pour les personnes qui en ont besoin. Les tests de sécurité au niveau de l’assistance relient ces objectifs aux paramètres convenus des comptes, des appareils et du réseau.

Teste uniquement les systèmes que tu es autorisé à tester et reste dans le périmètre convenu. Les analyses, les tentatives de deviner des mots de passe et de contourner les contrôles nécessitent une autorisation ; les tests d’intrusion spécialisés reposent sur un accord écrit.

Vérifier les identités et les autorisations

Applique le principe du moindre privilège : ne donne à un compte que les accès nécessaires à son rôle. Vérifie l’appartenance aux groupes, les partages requis, la politique de mots de passe, l’authentification multifacteur, le verrouillage, la désactivation des comptes invités ou inutilisés et la suppression des comptes des anciens membres du personnel. Change les mots de passe d’usine des appareils et des applications.

Utilise des actions autorisées et interdites. Confirme qu’un utilisateur standard peut ouvrir le dossier requis, puis confirme qu’un dossier à accès restreint refuse l’accès à ce rôle. Pour une installation nécessitant des droits d’administrateur, le résultat attendu est une demande d’identifiants d’administrateur à laquelle l’utilisateur standard ne peut pas répondre seul.

Un utilisateur standard n’est pas empêché d’installer tous les logiciels : certains programmes s’installent dans son profil. Si l’exigence interdit « toute installation de logiciel », une stratégie de contrôle des applications est également nécessaire et doit être testée. Ne transforme pas un contrôle des privilèges d’administrateur en affirmation plus large sur tous les logiciels.

Examiner les paramètres des appareils et du réseau

Vérifie l’état du pare-feu pour tous les profils réseau, la protection des terminaux active et ses définitions à jour, le chiffrement du disque, le verrouillage de l’écran après inactivité, les mises à jour requises et la désactivation des services ou de l’accès à distance inutiles. Confirme les ports réseau nécessaires et une protection Wi-Fi approuvée comme WPA2 ou WPA3.

Sous Windows, une invite autorisée avec élévation de privilèges peut exécuter manage-bde -status C:. Vérifie la présence de « Protection On » pour le disque système. PowerShell peut répertorier l’état des profils de pare-feu :

Get-NetFirewallProfile | Select-Object Name, Enabled

Domain, Private et Public doivent chacun afficher « True » lorsque l’exigence impose l’activation sur tous les profils. Pour un compte local, net user t.sales aide à examiner son état actif et son appartenance aux groupes. Sous macOS, fdesetup status indique l’état de FileVault. Consigne la sortie réelle et compare-la à l’exigence.

Maîtriser les données et les exceptions

Vérifie que les fichiers sensibles se trouvent dans des emplacements approuvés, accessibles uniquement aux rôles appropriés, et qu’ils sont protégés par chiffrement lorsque c’est requis. Supprime les données de test et les fichiers du technicien avant le transfert. Applique les messages de connexion et les paramètres de protection des données requis.

Cible les risques de configuration courants : autorisations trop larges, authentification faible, correctifs manquants, accès à distance exposé et paramètres par défaut non sécurisés. Un paramètre affiché dans un écran d’administration central ne suffit pas s’il n’a pas été appliqué à l’appareil.

Les paramètres de sécurité peuvent demander davantage d’efforts aux utilisateurs : les demandes d’authentification multifacteur et les délais de verrouillage plus courts en sont des exemples. Teste la politique convenue et consigne toute demande d’exception pour approbation par la personne responsable de la sécurité. Une préférence personnelle ne peut pas autoriser l’affaiblissement d’un contrôle requis.

Un résultat est utile lorsqu’une autre personne peut voir ce qui était attendu, ce qui s’est produit et comment les deux se comparent. Consigne les faits pendant les tests, y compris les échecs corrigés par la suite.

Choisir le statut à partir des preuves

Rédige le résultat attendu avant le test, à partir de l’exigence. Consigne le résultat observé tel qu’il se produit. Une correspondance signifie une réussite ; une différence signifie un échec. Évalue séparément la gravité de cette différence.

Une coupure réseau qui empêche un test de messagerie le rend bloqué. Elle ne démontre pas que la messagerie a réussi ou échoué. Garde cette lacune visible dans le rapport.

Rédiger des preuves utilisables par un collègue

Consigne les identifiants du cas et de l’exigence, l’appareil, le compte, le testeur, la date et l’heure exacte. Inclus les étapes, les mesures avec leurs unités, le texte et les codes d’erreur, les captures d’écran pertinentes et les entrées de journal. Utilise des dates sans ambiguïté comme 2026-10-21 et des termes de statut cohérents.

« L’impression ne fonctionne pas » laisse trop d’éléments à reconstituer. Un compte rendu plus solide est : « À 10 h 42, la tâche d’impression du traitement de texte est restée dans la file pendant 30 secondes, puis a affiché “Error – Printing” ; le journal du service d’impression a enregistré une erreur à 10 h 42. » Il distingue les observations visibles d’une hypothèse sur leur cause.

Chaque échec nécessite un rapport de défaut avec un identifiant unique, un titre, l’environnement, les étapes de reproduction, les résultats attendus et réels, les preuves, la gravité, la priorité et le statut actuel. Relie le rapport au test afin qu’une personne chargée de la revue puisse le suivre jusqu’à la correction et au nouveau test.

Séparer l’impact de l’urgence

La gravité mesure l’impact du défaut. La priorité mesure le délai dans lequel il doit être corrigé. Elles concordent souvent, mais servent à des décisions différentes. Une faute dans le nom de l’entreprise sur un écran de connexion est de faible gravité, mais peut être urgente avant un lancement destiné aux clients. Un problème à fort impact dans un rapport annuel peut avoir une priorité immédiate moindre lorsque ce rapport n’est pas attendu prochainement.

N’utilise pas une faible priorité pour masquer un impact élevé. La décision de mise en service tient toujours compte de la gravité et des exigences indispensables.

Indiquer la base de chaque taux

Supposons que 48 cas soient prévus : 42 réussissent, 3 échouent, 2 sont bloqués et 1 n’est pas exécuté. Les cas exécutés sont les réussites et les échecs : il y en a donc 45. Le taux de réussite des tests exécutés est d’environ 93,3 % ; celui des tests prévus est de 87,5 %. Les deux décrivent les mêmes résultats avec des dénominateurs différents.

Indique les nombres à côté des pourcentages afin que les trois cas non exécutés ne disparaissent pas derrière un taux élevé. Recherche des tendances entre appareils, heures, builds et réseaux : trois échecs provenant d’un même lot de livraison suggèrent une cause commune à examiner, sans la prouver.

Conserve l’échec initial lorsqu’une correction est apportée. Ajoute la correction et le résultat du nouveau test avec leurs dates. Écraser la ligne de l’échec détruit la preuve de ce qui a changé et rend le compte rendu trompeur.

Les journaux montrent des événements internes à un système qui peuvent ne pas apparaître à l’écran. Lis-les en parallèle du résultat de la tâche et des mesures de performance pour établir un compte rendu chronologique de ce qui s’est passé.

Trouver l’enregistrement pertinent

Un journal système est un relevé horodaté des événements, des erreurs et des activités d’accès. L’Observateur d’événements de Windows comprend les journaux Application, Sécurité, Installation, Système et Événements transférés, ainsi que les journaux des applications et des services propres aux composants. Les entrées comportent des champs tels que l’heure, la source, l’identifiant d’événement, le niveau et la description.

Les niveaux Windows comprennent Critique, Erreur, Avertissement, Information et Commentaires. Les événements de sécurité utilisent Audit des réussites ou Audit des échecs. Un audit des échecs peut être attendu dans un test négatif, comme une tentative de connexion interdite ; son sens dépend du résultat attendu du test.

Sous Linux, utilise journalctl pour le journal systemd et les fichiers pertinents sous /var/log. Sous macOS, utilise Console. Les niveaux de gravité syslog standard vont de 0, Urgence, à 7, Débogage, en passant par Alerte, Critique, Erreur, Avertissement, Notification et Information. Un nombre syslog plus faible indique une gravité plus élevée.

Faire le rapprochement par heure et par identité

Avant un test, vérifie l’horloge et le fuseau horaire de l’appareil. Note l’heure de chaque étape, puis filtre le journal pertinent sur cette plage et cette source. Lis les événements juste avant la défaillance ainsi que la défaillance elle-même. Compare avec le comportement normal de référence, car certains avertissements sont habituels.

Pour une connexion de lecteur réseau échouée à 10 h 42, un événement d’adresse IP à 10 h 41 min 58 s est suivi d’une expiration du délai DNS pour files.example.com à 10 h 42 min 05 s et d’une erreur de connexion du lecteur à 10 h 42 min 06 s. Conserve ensemble les entrées d’expiration du délai et de connexion du lecteur. Elles orientent l’investigation vers la résolution de noms ; elles n’établissent pas à elles seules la cause finale.

Comprendre les événements de compte

L’événement 4624 du journal Sécurité de Windows enregistre une connexion réussie ; 4625 enregistre une connexion échouée ; 4740 enregistre le verrouillage d’un compte. Ils dépendent de l’activation de l’audit. L’audit des échecs de connexion est nécessaire pour les entrées 4625 concernées ; 4740 nécessite l’audit des réussites de la gestion des comptes utilisateurs.

Un test de verrouillage peut produire plusieurs événements de connexion échouée, dont un autre lorsque le mot de passe correct est refusé après le verrouillage. Pour un compte de domaine, les preuves peuvent se trouver sur différents ordinateurs, notamment le contrôleur de domaine qui héberge le compte. Fais le rapprochement par compte, heure et ordinateur. Ne t’attends pas à une séquence fixe d’événements dans un seul journal.

Lire les alertes et les tendances dans leur contexte

Une alerte avertit une personne lorsqu’un événement défini se produit ou qu’un seuil est atteint : service arrêté, sauvegarde échouée ou disque presque plein. Crée sans danger une condition d’alerte requise dans l’environnement de test et confirme que l’alerte arrive. Consigne sa destination et son délai.

Les indicateurs de performance comprennent l’utilisation du processeur, la mémoire disponible, le stockage libre, l’activité du disque, le débit, la latence, la perte et le temps de réponse. Un bref pic du processeur à la connexion diffère d’une utilisation à 95 % pendant plusieurs minutes d’inactivité. Compare la durée, la charge de travail et la référence.

Recherche des intervalles répétés, des défaillances après redémarrage ou des problèmes limités à un sous-réseau. Copie les identifiants et messages pertinents dans le compte rendu des résultats. Un avertissement est un indice à interpréter, pas automatiquement un défaut, et un écran vide n’est pas une raison pour ignorer les journaux lors des tests critiques.

L’automatisation peut répéter un contrôle sur de nombreux systèmes sans omettre d’étapes par fatigue. Sa valeur dépend de ce que le contrôle prouve réellement et de la vérification de ses résultats par une personne.

Confier les tâches reproductibles aux outils

Les scripts PowerShell et Bash peuvent examiner les paramètres, les macros peuvent répéter des actions, les outils d’interface peuvent exécuter des tâches dans les applications et les outils de surveillance peuvent recueillir des métriques. Les analyseurs de configuration, de vulnérabilités et d’accessibilité comparent des caractéristiques sélectionnées à des règles ou à des références.

Ces outils sont utiles pour les tests de non-régression et les contrôles nécessaires sur chaque appareil. Une erreur de script se répète aussi sur chaque appareil : compare donc d’abord ses résultats avec un système connu et un contrôle manuel. Mets l’outil à jour lorsque le système change. La répétition rend une méthode cohérente ; elle ne rend pas exacte une méthode incorrecte.

Limiter l’affirmation à ce que vérifie le contrôle

Test-NetConnection files.example.com -Port 445 peut indiquer « TcpTestSucceeded : True. » Cela établit qu’une connexion TCP à ce port du serveur a réussi. Cela n’établit pas que l’utilisateur peut ouvrir un partage, créer un document ou l’enregistrer.

Pour prouver l’accès aux fichiers, exécute la tâche utilisateur avec les autorisations appropriées et examine son résultat. Un contrôle de port et un test fonctionnel de tâche apportent des preuves différentes. Les combiner peut aider à isoler une défaillance, mais l’un ne peut pas remplacer l’autre.

Un faux positif est un problème signalé qui n’est pas réel. Un faux négatif est un problème réel que l’outil ne détecte pas. Un faux positif peut faire perdre du temps ou retarder le transfert ; un faux négatif peut donner une fausse assurance. Leur gravité relative dépend du contrôle. Ne pas détecter un paramètre de sécurité dangereux est généralement plus grave que de le signaler inutilement pour examen.

Examiner un brouillon de l’IA avant de l’utiliser

Les outils d’IA peuvent suggérer des cas et des données de test, synthétiser des journaux, repérer des tendances possibles et rédiger des rapports. Ils peuvent aussi inventer des commandes, omettre des cas importants ou formuler des conclusions que les preuves ne justifient pas.

Relie les cas générés à la liste des exigences. Ajoute les contrôles négatifs, aux limites et d’accessibilité manquants. Vérifie les commandes proposées dans la documentation officielle, puis essaie-les dans l’environnement de test. Compare une synthèse du journal aux lignes brutes, notamment aux horodatages et aux comptes qu’elle prétend décrire.

Pour une plage de mots de passe de 12 à 64 caractères et un verrouillage après cinq échecs, un brouillon contenant un mot de passe de 15 caractères et un cas à cinq échecs est incomplet. Ajoute les longueurs 11, 12, 64 et 65, vérifie que quatre échecs ne verrouillent pas le compte et teste le déverrouillage. Définis des conditions initiales adaptées afin que chaque cas mesure la règle visée.

La personne qui donne l’approbation formelle reste responsable des résultats. La revue consiste notamment à vérifier si la conclusion d’un outil va au-delà de ses mesures, et pas seulement à corriger son orthographe.

Protéger les informations traitées

Utilise uniquement des services d’IA approuvés par l’organisation pour les documents de travail. Ne colle pas de mots de passe, de données personnelles, de journaux confidentiels ou de noms d’hôtes internes dans un service non approuvé. Masque les valeurs sensibles et respecte la charte informatique et les politiques de protection des données. Une synthèse utile ne justifie pas l’exposition des informations qu’elle résume.

Les contrôles d’aptitude à la mise en service confirment l’état de l’appareil ou du système réel juste avant son transfert. Les preuves issues des tests précédents peuvent concerner un build plus ancien, un autre compte ou un appareil de l’échantillon : conserve donc une liste de contrôle signée et datée pour chaque appareil livré.

Vérifier l’utilisateur et les connexions

Confirme que le compte existe, qu’il est activé et qu’il appartient aux bons groupes. Vérifie, selon le cas, la connexion, le changement du mot de passe temporaire et la configuration de l’authentification multifacteur. Supprime les comptes de test et le profil du technicien, et évite d’accorder des droits d’administrateur sauf si le rôle l’exige.

Vérifie l’adresse, la passerelle et les serveurs DNS. Sous Windows, ipconfig /all affiche la configuration IP. Sous Linux, ip a affiche les adresses, ip route affiche les routes, dont la passerelle par défaut, et resolvectl status affiche le DNS sur les systèmes utilisant systemd-resolved. ip a seul ne permet pas d’établir la configuration de la passerelle ou du DNS.

Utilise ping pour vérifier si les cibles réseau répondent, nslookup pour la résolution de noms et un contrôle du port de service comme Test-NetConnection pour les services requis. Effectue ensuite la tâche réelle. Certains réseaux bloquent le ping : une absence de réponse ne suffit donc pas à établir que tous les services sont indisponibles. Confirme les profils Wi-Fi, le VPN, les partages et les imprimantes requis.

Comparer le stockage à l’exigence

Vérifie l’espace libre, les quotas, le stockage réseau, la synchronisation dans le cloud et la sauvegarde. Un disque vendu pour 512 Go contient 512 milliards d’octets. La division par 2³⁰ donne environ 476,8 Gio ; Windows indique généralement « Go » pour ce nombre fondé sur une unité binaire.

Pour un critère d’« au moins 20 % d’espace libre », utilise les valeurs libre et totale sur la même base de mesure. Vingt pour cent de 476,8 représentent environ 95,4. Avec 61,2 libres, la proportion est d’environ 12,8 % : le contrôle échoue donc. Supprime les programmes d’installation et les fichiers de test restants si nécessaire, puis mesure à nouveau. Comparer 61,2 aux 512 annoncés à la vente sans tenir compte des unités mélangerait les bases.

Confirmer les mises à jour et la protection

Vérifie les versions du système d’exploitation, des applications, des navigateurs, des pilotes et des micrologiciels par rapport aux versions requises. Effectue les redémarrages en attente et mets à jour les définitions de la protection des terminaux. Windows Update et winver, Mise à jour de logiciels sous macOS et le gestionnaire de paquets Linux fournissent des éléments de preuve utiles.

Vérifie le chiffrement du disque, le pare-feu, la protection active des terminaux, le délai de verrouillage de l’écran, la modification des mots de passe par défaut et la désactivation des services inutiles. Confirme les paramètres approuvés de stockage et de sauvegarde des fichiers sur l’appareil lui-même, pas uniquement dans une console d’administration qui indique que la stratégie a été envoyée.

Terminer par la tâche en fonctionnement

Effectue un test fumigatoire des fonctions et des performances attendues. Réalise les tâches destinées à l’utilisateur avec son compte ou un compte équivalent. Utilise des privilèges d’administrateur autorisés uniquement pour les contrôles qui les nécessitent, comme un outil de vérification de l’état du chiffrement exécuté avec élévation de privilèges.

Si un profil VPN manque, consigne l’échec du contrôle, ajoute le profil selon la procédure approuvée, puis vérifie à nouveau l’accès VPN et les tâches concernées. Conserve la correction et le nouveau contrôle dans le dossier de cet appareil. Vérifier un autre ordinateur portable du même modèle n’établit pas l’état de celui-ci.

Une recommandation de mise en service compare les preuves aux exigences et aux critères de sortie. Le responsable du système doit voir ce qui a réussi, ce qui reste ouvert et quels risques seraient acceptés si l’utilisation commençait maintenant.

Construire la décision à partir des comptes rendus

Commence par prendre en compte chaque cas prévu, y compris les tests bloqués et ignorés. Confirme les exigences indispensables, examine les défauts selon leur gravité et termine la liste de contrôle d’aptitude à la mise en service. Évalue le risque des problèmes ouverts et l’effet d’un report. Rédige une recommandation motivée pour la personne autorisée à accepter le système.

Les conclusions habituelles sont prêt, prêt sous réserve et non prêt. Les réserves précisent les problèmes mineurs connus, les solutions de contournement utilisables et une date de correction. Un problème non résolu de gravité élevée qui affecte une exigence indispensable bloque généralement la mise en service ; les critères de sortie convenus déterminent la décision.

Un taux de réussite global élevé ne peut pas annuler l’échec d’une exigence indispensable. De même, un problème à faible impact ne doit pas nécessairement retarder tous les appareils si le responsable peut l’accepter selon les critères.

Distinguer les systèmes concernés

Pour 12 ordinateurs portables commerciaux, supposons que trois perdent l’accès VPN après dix minutes d’inactivité et que tous aient un fond d’écran incorrect. L’utilisation du VPN à distance est indispensable et les critères de sortie n’autorisent aucun défaut ouvert de gravité élevée.

Les trois appareils présentant le défaut VPN ne sont pas prêts tant qu’ils n’ont pas été corrigés et testés à nouveau. Les neuf autres peuvent être recommandés pour le transfert, avec le problème de fond d’écran de faible gravité consigné et accepté. Identifie chaque appareil dans la décision ; une affirmation portant sur l’ensemble du lot masquerait la différence.

Le même principe ne s’applique à une partie des tâches que si le responsable a accepté ce périmètre. Un technicien ne peut pas retirer discrètement une exigence échouée pour obtenir un résultat réussi.

Appliquer le seuil convenu

Un critère de « 95 % de 20 chargements en moins de 2 secondes » nécessite 19 chargements conformes. Dix-huit donnent 90 %, ce qui constitue un échec même si les personnes trouvent l’application rapide. Consigne l’écart comme un échec. Si le responsable accepte le risque, conserve la mesure échouée et consigne qui a accepté l’exception.

Les exigences peuvent entrer en conflit dans la pratique. Une analyse des logiciels malveillants au démarrage peut ralentir la connexion, ou l’authentification multifacteur peut ajouter une étape. Indique le coût mesuré, le bénéfice de sécurité exigé par la politique et le compromis approuvé. Ne modifie pas discrètement un seuil et n’affaiblis pas un contrôle pour faire paraître les deux tests réussis.

Rendre le rapport vérifiable

Un rapport de synthèse des tests indique le périmètre, l’environnement et les dates ; les nombres par statut ; les taux de réussite et leurs bases ; les défauts ouverts et leurs gravités ; les écarts par rapport au plan ; les risques restants ; et la recommandation motivée. Relie les conclusions aux résultats des cas, aux journaux ou aux preuves des listes de contrôle.

« Aucun défaut trouvé » décrit les tests qui ont été exécutés. Inclus les domaines non testés afin que cette formule ne puisse pas être interprétée comme une promesse d’absence totale de défauts. Atteindre une échéance ne satisfait pas non plus aux critères de sortie : tout risque accepté doit être consigné par le responsable concerné.

Après une mise à jour ou une modification de configuration, utilise des tests de non-régression et des contrôles d’aptitude à la mise en service pour confirmer que le système reste utilisable. Une acceptation antérieure s’applique à l’état testé ; un comportement modifié nécessite de nouvelles preuves.

Le transfert fournit aux utilisateurs un système fonctionnel et donne à l’équipe d’assistance assez d’informations pour le maintenir. L’acceptation consigne qui a reconnu que le système était prêt, quand et sous quelles éventuelles conditions.

Préparer ce dont chaque public a besoin

Les utilisateurs ont besoin de l’appareil ou du service, des informations de connexion transmises de manière sécurisée, d’un court guide de démarrage rapide, des applications installées et des ressources connectées, des problèmes connus et de leurs solutions de contournement, ainsi que des instructions pour obtenir de l’aide. Les collègues techniques ont aussi besoin de la fiche de configuration et des preuves relatives aux problèmes acceptés.

Consigne les décisions de configuration et leurs raisons. « Verrouillage de l’écran après cinq minutes, exigé par la politique de sécurité » explique davantage que le seul paramètre. « Mise à l’échelle de l’affichage à 150 % en raison d’une malvoyance » aide le technicien suivant à conserver un réglage important lors de l’assistance ou d’une reconstruction.

Le manager a besoin de connaître le résultat de la décision de mise en service, les risques restants et les décisions nécessitant une approbation. Un utilisateur a généralement besoin des actions à effectuer lors de la première connexion et de la marche à suivre pour ses tâches quotidiennes. Envoyer le même rapport technique aux deux rend les informations utiles plus difficiles à trouver.

Transmettre les accès de manière sécurisée

Envoie le nom d’utilisateur et le mot de passe temporaire par des canaux distincts. Exige le changement du mot de passe temporaire à la première connexion. Ne laisse pas de mot de passe attaché à l’appareil et ne l’inclus pas dans le même message que le nom d’utilisateur.

Confirme la configuration de l’authentification multifacteur ou la procédure convenue pour sa première utilisation. Supprime les comptes de test, les fichiers de test et les accès inutiles du technicien avant que l’utilisateur prenne la responsabilité de l’appareil. L’équipe d’assistance ne devrait pas avoir à deviner quelles modifications temporaires subsistent.

Consigner l’acceptation par l’utilisateur

Demande à l’utilisateur ou au responsable du système d’effectuer les tâches essentielles, souvent lors d’une courte démonstration ou d’une séance de test d’acceptation utilisateur. Utilise des données d’exemple réalistes dans un environnement de formation lorsque l’exercice ne doit pas affecter le travail en production.

L’approbation formelle consigne la date, la personne qui accepte et les éventuelles conditions. Les problèmes connus doivent être accompagnés de leurs solutions de contournement et des dates de correction convenues. Un appareil livré sur un bureau sans acceptation ne constitue pas un dossier de transfert complet.

Un message à l’utilisateur peut dire : « Ton nouvel ordinateur portable est prêt. Connecte-toi avec ton nom d’utilisateur habituel et choisis un nouveau mot de passe lorsque cela t’est demandé. Si le deuxième écran reste noir après la mise en veille, débranche puis rebranche le câble de la station d’accueil. Contacte le centre de services si le problème persiste. » La solution de contournement donne une action que la personne peut effectuer ; les conclusions techniques restent dans le dossier d’assistance.

Assurer l’assistance pendant les premiers jours d’utilisation

Présente brièvement les nouvelles fonctions ou les procédures de travail modifiées. Oriente les utilisateurs vers le centre de services et montre-leur comment créer un ticket. Enregistre les demandes, réponds dans les délais de service convenus et transmets au niveau supérieur les problèmes que tu ne peux pas résoudre. Communique avec respect et évite de promettre une date de correction qui n’a pas été confirmée.

Surveille attentivement les journaux, les alertes et les retours des utilisateurs après le transfert. Certaines défaillances n’apparaissent qu’avec des charges de travail réelles ou des tâches moins courantes. Ajoute les enseignements utiles à la liste de contrôle et au plan de test pour le prochain déploiement. Un problème connu accepté reste visible pour les utilisateurs et l’assistance jusqu’à sa résolution et son nouveau test.