Tests logiciels en PME : quoi vérifier avant la mise en production

Avant de mettre en production un site, une automatisation ou un logiciel métier, une PME doit d’abord tester ce qui pourrait interrompre une vente, fausser une donnée, ouvrir un accès indu ou empêcher le retour à un état stable. Le bon plan de test n’est pas le plus long. C’est celui qui couvre les conséquences les plus graves pour l’activité.

Cette approche évite deux extrêmes : publier après un simple contrôle visuel, ou accumuler une liste de tests impossible à maintenir. Elle donne aussi au dirigeant des critères concrets pour accepter, retarder ou limiter une mise en production.

Partir du risque métier, pas de la liste des fonctionnalités

Un prochain webinaire annoncé par La French Tech Est pose une question utile : quel niveau de test répond réellement aux besoins de l’organisation ? L’enjeu ne consiste pas à tester davantage par principe, mais à choisir une couverture cohérente avec le produit et ses conséquences.

Le Secure Software Development Framework du NIST suit la même logique de proportion. Il propose des pratiques orientées résultats, à adapter au risque, au coût, à la faisabilité et aux ressources. Il précise que le cadre ne doit pas devenir une checklist appliquée sans réflexion.

Pour une PME, le point de départ tient donc en une phrase : décrire ce qui se passe si cette fonction échoue en conditions réelles.

Un défaut sur une animation secondaire n’a pas le même poids qu’un panier qui calcule mal un montant, qu’un formulaire qui perd des demandes ou qu’une automatisation qui envoie deux fois une facture. Le périmètre prioritaire apparaît lorsque l’on relie chaque fonction à une conséquence observable.

Les quatre contrôles à exiger avant de publier

1. Le parcours critique fonctionne de bout en bout

Choisissez un petit nombre de scénarios qui représentent l’activité réelle. Pour un site marchand, cela peut aller de l’arrivée sur une fiche produit jusqu’à la confirmation de commande. Pour un outil interne, le scénario peut couvrir la création d’un dossier, sa validation et sa transmission à la personne suivante.

Un bon test de parcours utilise des données proches du réel, sans exposer de données personnelles de production. Il vérifie le résultat final, mais aussi les étapes intermédiaires : changement de statut, notification, pièce créée, stock ajusté ou donnée transmise au bon système.

Testez au minimum le cas normal, un abandon en cours de route et une entrée invalide. L’objectif n’est pas d’explorer toutes les combinaisons. Il est de savoir si le chemin qui produit du chiffre d’affaires ou fait avancer le travail reste fiable.

2. Les données restent justes en cas d’erreur

Beaucoup d’incidents ne rendent pas l’outil indisponible. Ils le laissent fonctionner avec une information fausse, incomplète ou dupliquée. Ces erreurs silencieuses sont difficiles à repérer et peuvent contaminer la facturation, le suivi commercial ou le reporting.

Il faut donc provoquer les situations imparfaites : une API qui répond trop tard, un fichier mal formé, un envoi répété, une valeur absente ou une interruption entre deux étapes. Vérifiez ensuite si l’opération est refusée proprement, mise en attente ou relancée sans créer de doublon.

Pour une automatisation, posez une règle simple : la même entrée exécutée deux fois ne doit pas produire deux effets métier lorsqu’un seul est attendu. Si cette propriété n’est pas garantie, le dispositif doit au moins détecter et signaler le doublon.

3. Chaque rôle ne voit et ne modifie que ce qui lui revient

La connexion réussie d’un administrateur ne prouve pas que les droits sont corrects. Testez séparément les profils réels : visiteur, client, salarié, responsable, prestataire et administrateur selon le projet.

Essayez d’ouvrir directement une ressource qui ne devrait pas être accessible. Vérifiez qu’un utilisateur déconnecté ne conserve pas un accès sensible, qu’un ancien compte peut être révoqué et qu’une action critique laisse une trace exploitable.

L’OWASP Application Security Verification Standard fournit une base ouverte pour vérifier les contrôles techniques des applications web. Il peut aussi servir à formuler des exigences dans un contrat. Une petite entreprise n’a pas besoin d’appliquer chaque exigence au même niveau. Elle peut demander au prestataire quelles familles de contrôles ont été couvertes, sur quel périmètre et avec quelles preuves.

4. L’équipe sait revenir à un état stable

Une mise en production n’est pas prête tant que le retour arrière reste théorique. Avant le lancement, identifiez la version précédente, les changements de base de données, les dépendances externes et la personne autorisée à décider l’arrêt.

Le test utile consiste à restaurer réellement un environnement ou un petit jeu de données. Une sauvegarde dont la restauration n’a jamais été essayée reste une hypothèse. Pour une automatisation, prévoyez aussi le traitement des opérations restées en attente pendant l’arrêt.

Le retour arrière n’est pas toujours la meilleure option. Une migration de données irréversible peut imposer une correction en avant. Cette limite doit être connue avant la publication, pas découverte pendant l’incident.

Transformer ces contrôles en décision de mise en production

Une réunion de validation peut tenir sur une page. Pour chaque parcours critique, notez : le risque métier, le test exécuté, le résultat obtenu, la preuve disponible, le défaut restant et la décision associée.

Les décisions possibles ne se limitent pas à « oui » ou « non » :

• publier normalement si les risques critiques sont couverts ;
• publier sur un périmètre réduit si l’impact peut être contenu ;
• désactiver une fonction secondaire encore fragile ;
• retarder si une erreur menace les données, les accès ou la continuité ;
• accepter un défaut mineur avec un responsable et une échéance de correction.

Cette gradation évite qu’un détail cosmétique bloque tout le projet. Elle empêche aussi qu’une date de lancement fasse oublier un risque important.

Les preuves à demander à un prestataire

Une affirmation comme « les tests sont passés » est trop vague. Demandez un compte rendu court contenant les scénarios exécutés, l’environnement utilisé, la date, le résultat et les défauts connus. Pour les fonctions critiques, une capture, un journal technique ou un rapport automatisé permet de vérifier que le test a réellement eu lieu.

Demandez aussi ce qui n’a pas été testé. Cette information protège mieux qu’une promesse générale de qualité. Elle distingue une limite connue d’un angle mort.

Enfin, conservez les tests prioritaires après la livraison. Ils devront être rejoués lors d’une mise à jour du site, d’un changement d’API, d’une évolution du logiciel ou de l’ajout d’une automatisation. Un test n’est pas seulement une étape avant le lancement. C’est un moyen de détecter qu’une fonction déjà fiable vient d’être cassée.

Mettre en production avec une incertitude maîtrisée

Aucun protocole raisonnable ne garantit l’absence totale de défaut. Le rôle des tests est de réduire l’incertitude là où une erreur coûterait réellement à l’entreprise.

Pour une TPE ou une PME, quatre questions suffisent à structurer la décision : le parcours critique aboutit-il, les données restent-elles justes, les droits sont-ils correctement séparés et le système peut-il retrouver un état stable ?

Si les réponses reposent sur des essais observables plutôt que sur des déclarations, la mise en production devient une décision de gestion. Pas un pari pris la veille du lancement.