← Retour au portail

Fiche 2 - Tests d'intégration et d'acceptation d'un service

Distinguer les types de tests informatiques, rédiger des cas de test pertinents et valider un service avant sa mise à disposition.

Intermédiaire — SISR 1ère et 2ème année ⏱️ 20 min 📁 Déploiement de services

🎯 Objectifs de la fiche

  1. Pourquoi tester avant la mise en production ? — Enjeux techniques et humains
  2. Types de tests — Unitaires, intégration, acceptation, charge
  3. Rédiger un cas de test — Structure, critères de réussite
  4. Le rapport de test — Contenu, traçabilité
  5. Tests d'acceptation utilisateur (UAT) — Dimension humaine de la validation

Prérequis

Connaître les bases du déploiement d'un service (voir fiche précédente). Cette fiche est au programme du Bloc 1 (B1.5 — Réaliser les tests d'intégration et d'acceptation d'un service).

1. Pourquoi tester avant la mise en production ?

Un service non testé présente un risque élevé de dysfonctionnement en production, avec un impact direct sur les utilisateurs. Les tests permettent de vérifier deux dimensions complémentaires : la dimension technique (le service fonctionne-t-il correctement ?) et la dimension humaine (le service répond-il aux attentes des utilisateurs ?).

2. Types de tests informatiques

Type de testObjectifQui le réalise
Test unitaireVérifier le bon fonctionnement d'un composant isoléDéveloppeur / technicien
Test d'intégrationVérifier que les composants fonctionnent bien ensembleÉquipe technique
Test de chargeVérifier le comportement sous forte sollicitationÉquipe technique
Test de sécuritéVérifier l'absence de vulnérabilités exploitablesÉquipe sécurité / pentester
Test d'acceptation (UAT)Vérifier que le service répond aux besoins métierUtilisateurs finaux / client
ℹ️ UAT signifie User Acceptance Testing — c'est la dernière étape de validation avant la mise en production, réalisée par de vrais utilisateurs dans des conditions proches de la réalité.

3. Rédiger un cas de test

Un bon cas de test doit être précis, reproductible et avoir un résultat attendu clairement défini.

Exemple de cas de test — déploiement d'un nouveau service VPN

ID du test       : TEST-VPN-001
Titre             : Connexion VPN avec identifiants valides
Préconditions     : Compte utilisateur créé, client VPN installé
Étapes            :
  1. Lancer le client VPN
  2. Saisir login/mot de passe valides
  3. Cliquer sur "Connexion"
Résultat attendu  : Connexion établie en moins de 10 secondes,
                    adresse IP du réseau interne attribuée
Résultat obtenu   : [à compléter lors du test]
Statut            : [Réussi / Échoué]
Élément du cas de testPourquoi c'est important
PréconditionsGarantir que le test démarre dans un état connu et reproductible
Étapes précisesPermettre à n'importe qui de rejouer le test à l'identique
Résultat attenduDéfinir objectivement ce qui constitue un succès
Cas limitesTester aussi les cas d'erreur (mot de passe incorrect, réseau coupé...)
💡 Ne testez pas uniquement le 'chemin heureux' (cas où tout fonctionne). Testez aussi les cas d'erreur : identifiants incorrects, perte de connexion, données invalides. Ces cas révèlent souvent les vrais problèmes.

4. Plan de test

Le plan de test rassemble l'ensemble des cas de test à exécuter pour valider un service, organisés par fonctionnalité ou par criticité.

Catégorie de testExemple de cas pour un service VPN
Fonctionnel de baseConnexion avec identifiants valides
Cas d'erreurConnexion avec mot de passe incorrect
LimiteConnexion simultanée de plusieurs utilisateurs au maximum prévu
SécuritéTentative de connexion depuis une IP non autorisée
PerformanceDébit réseau via VPN comparé au réseau local

5. Le rapport de test

SectionContenu
SynthèseNombre de tests exécutés, réussis, échoués
Détail des résultatsChaque cas de test avec son statut et ses observations
Anomalies détectéesDescription précise des dysfonctionnements rencontrés
RecommandationAvis sur la mise en production : Go / No-Go

6. Tests d'acceptation utilisateur (UAT)

Les tests d'acceptation impliquent les utilisateurs finaux dans des conditions proches de la réalité. Cette étape a une dimension humaine forte : elle valide non seulement le fonctionnement technique, mais aussi l'ergonomie et l'adéquation aux besoins réels.

Bonne pratique UATPourquoi
Sélectionner des utilisateurs représentatifsÉviter de tester uniquement avec des experts techniques
Fournir un scénario réalisteTester des situations métier réelles, pas seulement des fonctions isolées
Recueillir le ressenti utilisateurDétecter les problèmes d'ergonomie invisibles aux tests techniques
Documenter les retoursCapitaliser pour les évolutions futures du service
⚠️ Un service peut être techniquement parfait et pourtant rejeté par les utilisateurs s'il est mal conçu du point de vue ergonomique. Les tests d'acceptation ne sont pas une formalité — c'est souvent là que se révèlent les vrais problèmes d'adoption.
🎯 Passer l'évaluation de cette fiche