Votre prestataire dit que « tout est prêt ». Comment le vérifier sans être technicien ? Voici douze questions qui permettent de distinguer un projet réellement prêt d’un projet qui n’a simplement pas encore planté. Pour chacune, nous donnons la bonne réponse et le signal d’alerte.

Ces questions viennent de ce que nous voyons en testant des logiciels avant et après leur mise en production : les pannes les plus coûteuses viennent rarement d’un bug évident, presque toujours d’une situation que personne n’avait testée.

Charge : tiendra-t-il le jour J ?

1. Avez-vous testé avec autant d’utilisateurs simultanés que notre pic réel, et au-delà ?

• Bonne réponse : « Oui, voici les résultats à 1, 20, 50 puis 100 utilisateurs, et ce qui se passe au-delà. »
• Signal d’alerte : « Nous avons testé avec l’équipe. » Cinq testeurs ne prouvent rien : certains défauts n’apparaissent qu’à partir d’un seuil précis.

2. Avez-vous testé avec le volume de données que nous aurons dans deux ans ?

• Bonne réponse : « Oui, avec dix fois puis cinquante fois le volume actuel, voici comment les temps évoluent. »
• Signal d’alerte : Tests faits uniquement sur une base presque vide. Un logiciel rapide avec mille lignes peut devenir lent avec cent mille.

3. Que voit l’utilisateur quand le système est saturé ?

• Bonne réponse : « Une erreur claire en quelques secondes, et le reste de l’application continue de répondre. »
• Signal d’alerte : Un écran qui tourne pendant une minute, ou une application entière bloquée à cause d’un seul écran lourd.

Données et sécurité : qui voit quoi ?

4. Comment prouvez-vous qu’un client ne voit jamais les données d’un autre ?

• Bonne réponse : « Un test compare, pour chaque rôle, ce que l’application renvoie à ce que la base autorise, et tente des accès directs à des données d’autres clients : tous sont refusés. »
• Signal d’alerte : « C’est géré dans le code. » Une affirmation n’est pas une preuve.

5. Que se passe-t-il si quelqu’un modifie un identifiant dans l’adresse d’une page ?

• Bonne réponse : « L’accès est refusé, nous le testons systématiquement. »
• Signal d’alerte : Pas de réponse précise. C’est la faille la plus classique des applications web.

6. Les rôles (administrateur, collaborateur, consultant) sont-ils testés écran par écran ?

• Bonne réponse : « Une matrice rôles contre écrans est rejouée à chaque version. »
• Signal d’alerte : Les droits ne sont vérifiés qu’à la main, une fois, avant la livraison.

Supervision : le saurez-vous avant vos utilisateurs ?

7. Serons-nous alertés avant les utilisateurs si un service ralentit ?

• Bonne réponse : « Des alertes se déclenchent sur les temps de réponse, les erreurs et la saturation de la base. »
• Signal d’alerte : Vous apprenez les pannes par vos utilisateurs.

8. Quels indicateurs surveillez-vous ?

• Bonne réponse : Temps de réponse, taux d’erreurs, connexions à la base de données en attente, redémarrages.
• Signal d’alerte : Seulement « le serveur est allumé ».

9. Que contiennent les journaux, et qui les lit ?

• Bonne réponse : Des erreurs claires, centralisées, avec quelqu’un d’identifié pour les traiter.
• Signal d’alerte : Des journaux que personne ne consulte avant l’incident.

Reprise : et si ça se passe mal ?

10. Pouvez-vous revenir à la version précédente en moins de 15 minutes ? L’avez-vous déjà fait en répétition ?

• Bonne réponse : « Oui, et nous l’avons répété. »
• Signal d’alerte : Un retour arrière jamais essayé : il échouera le jour où vous en aurez besoin.

11. Les sauvegardes de la base sont-elles restaurées régulièrement, pas seulement créées ?

• Bonne réponse : « Une restauration complète est testée à intervalles réguliers. »
• Signal d’alerte : « Les sauvegardes tournent toutes les nuits », sans jamais avoir été restaurées.

Preuves

12. Pouvez-vous nous montrer les résultats des tests, y compris ceux qui ont échoué et ce qui a été corrigé ?

• Bonne réponse : Un rapport avec les échecs trouvés, les corrections et les nouvelles mesures.
• Signal d’alerte : Un rapport où tout est vert. Des tests qui ne trouvent jamais rien sont des tests qui ne cherchent pas.

Comment utiliser cette liste

Posez ces douze questions par écrit et demandez des preuves : captures de résultats, rapports, noms des outils. Un bon prestataire apprécie ces questions, car elles lui permettent de montrer son travail. Une réponse floue sur plus de trois points est un signal sérieux : mieux vaut décaler la mise en production de quelques jours que la subir.

Pour approfondir deux points de cette liste, lisez notre article sur les tests de charge et celui sur la sécurité des données entre clients. Pour les aspects de sécurité plus généraux, consultez aussi notre guide de la cybersécurité des PME au Maroc.

Questions fréquentes

À partir de quelle taille de projet cette checklist est-elle utile ? Dès qu’un logiciel sert plusieurs personnes ou plusieurs clients en même temps. Plus les données sont sensibles, plus les questions 4 à 6 sont importantes.

Faut-il être technicien pour la remplir ? Non. Vous n’avez pas à juger la réponse technique, seulement à vérifier qu’une preuve existe.

Et si la réponse est « non » à plusieurs questions ? Ce n’est pas une catastrophe : cela dit ce qu’il faut faire avant de lancer. Chaque « non » devient une tâche priorisée.

Passons cette liste ensemble

Chez Neologix, nous passons cette checklist avec vous sur votre projet en 30 minutes, et nous proposons un audit complet si nécessaire. Contactez-nous.