OUI, mais de façon CIBLÉE : n'essayez pas de tout tester, concentrez-vous sur le cœur métier (calculs et règles critiques) et sur les bugs déjà rencontrés. Quelques tests bien choisis rapportent beaucoup ; une couverture exhaustive coûterait plus qu'elle ne rapporte sur un petit projet. L'objection habituelle (et sa part de vérité) : (1) « Écrire des tests prend du temps que je n'ai pas. » C'est vrai : les tests représentent un investissement initial réel. (2) Sur un petit projet stable qui ne bougera plus, l'intérêt est effectivement limité. (3) Une couverture exhaustive (tester chaque procédure, chaque écran) est disproportionnée pour une petite application. Pourquoi l'investissement se justifie quand même : (1) Une application de gestion VIT LONGTEMPS et évolue en permanence : nouvelles règles, changements réglementaires, demandes des utilisateurs. Le « petit projet » d'aujourd'hui est maintenu pendant des années. (2) Le vrai coût n'est pas d'écrire le test, c'est de NE PAS l'avoir quand une modification casse silencieusement un calcul et qu'un client s'en aperçoit trois mois plus tard sur sa facturation. La correction, les explications et la perte de confiance coûtent bien plus cher. (3) Retester manuellement est illusoire : après chaque modification, personne ne reteste toute l'application. On teste ce qu'on vient de modifier, et les régressions passent. (4) Les tests donnent la CONFIANCE de modifier. C'est leur bénéfice le plus sous-estimé : sans tests, on hésite à toucher au code existant, on empile des rustines plutôt que d'améliorer. Avec des tests, on refactorise sereinement. (5) Ils servent aussi de DOCUMENTATION : un test montre comment une procédure doit se comporter, y compris dans les cas particuliers. Par quoi commencer (le plus rentable) : (1) Les CALCULS et RÈGLES MÉTIER critiques : TVA, remises, échéances, totaux, calculs de stock, tarification. Ce sont les endroits où une erreur coûte le plus cher — et ce sont les plus faciles à tester (des entrées, un résultat attendu). (2) Les CAS LIMITES de ces règles : zéro, valeurs vides, montants négatifs, arrondis, dates de changement d'année, valeurs extrêmes. (3) Chaque BUG corrigé : écrivez un test qui reproduit le bug avant de le corriger. Il échoue, vous corrigez, il passe — et il garantit que ce défaut précis ne reviendra jamais. C'est la pratique la plus rentable qui soit, et elle construit progressivement une base de tests utile. (4) Un ou deux SCÉNARIOS d'interface sur les parcours les plus critiques (saisir et valider une commande de bout en bout). Ce qu'il ne faut PAS faire : (1) Viser 100 % de couverture sur un petit projet : effort disproportionné. (2) Tester des choses triviales (un accesseur qui ne fait rien). (3) Laisser les tests devenir obsolètes : des tests qui échouent en permanence et qu'on ignore sont PIRES que rien — ils créent un faux sentiment de sécurité et finissent par être désactivés. Mieux vaut peu de tests fiables que beaucoup de tests morts. En résumé : OUI, même sur un petit projet — à condition d'être CIBLÉ. Ne visez pas l'exhaustivité (disproportionnée à cette échelle) mais concentrez l'effort là où il rapporte : les CALCULS et RÈGLES MÉTIER critiques (TVA, remises, échéances, stocks, tarification), qui sont à la fois les plus coûteux en cas d'erreur et les plus simples à tester, leurs CAS LIMITES (zéro, valeurs vides, négatifs, arrondis, changements d'année) où se logent la plupart des bugs, et surtout un test à CHAQUE BUG CORRIGÉ — pratique la plus rentable de toutes, qui garantit qu'un défaut ne reviendra jamais et construit progressivement une base de tests réellement utile. Ajoutez-y un ou deux scénarios d'interface sur les parcours critiques. La justification tient à trois faits : une application de gestion vit et évolue pendant des années, retester manuellement l'ensemble après chaque modification est illusoire (on ne teste que ce qu'on vient de changer, et les régressions passent), et le coût d'un calcul silencieusement cassé découvert des mois plus tard par un client dépasse de loin celui d'écrire le test. Le bénéfice le plus sous-estimé reste la CONFIANCE de modifier : sans tests, on n'ose plus toucher au code et on empile les rustines. Attention toutefois : des tests obsolètes qu'on ignore sont pires que pas de tests.

En regardant plusieurs dimensions objectives : elle fait ce qu'elle doit (JUSTESSE), elle résiste aux imprévus (ROBUSTESSE), elle est utilisable efficacement (ERGONOMIE), elle reste rapide sur des volumes réels (PERFORMANCE) et elle peut évoluer sans douleur (MAINTENABILITÉ) — le tout validé par les utilisateurs réels. Les dimensions à évaluer : (1) JUSTESSE (la plus importante). Les résultats sont-ils exacts ? En gestion, un total faux, une TVA erronée ou un stock incohérent sont des défauts graves — d'autant plus dangereux qu'ils ne provoquent aucune erreur visible : l'application ne plante pas, elle MENT. Vérifiez vos calculs sur des cas connus. (2) ROBUSTESSE. Que se passe-t-il si le réseau tombe, si un fichier est absent, si l'utilisateur saisit n'importe quoi, si deux personnes modifient la même fiche ? Une application de qualité ne plante pas devant l'utilisateur et ne laisse jamais les données dans un état incohérent. (3) ERGONOMIE / efficacité. Les utilisateurs travaillent-ils vite ? Se plaignent-ils de clics inutiles, de saisies redondantes, de messages incompréhensibles ? (4) PERFORMANCE sur volumes RÉELS. Une application rapide sur mille enregistrements peut être inutilisable sur un million. C'est un test à faire explicitement. (5) MAINTENABILITÉ. Pouvez-vous ajouter une fonctionnalité sans tout casser ? Comprenez-vous encore votre code six mois après ? Un collègue peut-il reprendre le projet ? C'est la dimension la moins visible et la plus coûteuse à long terme. (6) SÉCURITÉ : droits appropriés, données protégées, traçabilité des opérations sensibles. (7) DÉPLOYABILITÉ : l'installation et les mises à jour se passent-elles sans incident ? Les signaux d'ALERTE : (1) Vous avez peur de modifier certaines parties du code. (2) Les mêmes bugs reviennent régulièrement. (3) Chaque correction en provoque une autre (régressions). (4) Vous ne savez plus où se trouve une règle métier (elle est dupliquée). (5) Les utilisateurs contournent l'application (fichiers parallèles, ressaisies). (6) Les traitements ralentissent au fil des mois. (7) Personne d'autre que vous ne peut intervenir. Comment mesurer concrètement : (1) ÉCOUTEZ les utilisateurs : ce sont eux qui subissent la qualité au quotidien. Leurs plaintes récurrentes sont vos meilleurs indicateurs. (2) Comptez les INCIDENTS : combien de bugs signalés par mois ? sont-ils graves ? récurrents ? (3) Mesurez le TEMPS nécessaire pour ajouter une fonctionnalité : s'il s'allonge, la dette technique grossit. (4) Testez avec des volumes réels et des cas limites. (5) Faites RELIRE votre code par un pair si possible : le regard extérieur voit ce que vous ne voyez plus. (6) Utilisez l'AUDIT du projet fourni par l'atelier. Comment progresser : (1) Corrigez les CAUSES (duplication, code dans les boutons) et pas seulement les symptômes. (2) Ajoutez des TESTS sur ce qui casse souvent. (3) Documentez le minimum utile. (4) Améliorez en continu plutôt que d'attendre une refonte hypothétique. En résumé : évaluez la qualité sur plusieurs dimensions objectives plutôt que sur une impression. La JUSTESSE d'abord — en gestion, un total ou une TVA erronés sont les pires défauts précisément parce qu'ils sont silencieux : l'application ne plante pas, elle ment. Puis la ROBUSTESSE (réseau coupé, saisies aberrantes, accès concurrents : ni plantage, ni données incohérentes), l'ERGONOMIE mesurée à la vitesse de travail réelle des utilisateurs, la PERFORMANCE testée sur des VOLUMES RÉELS (ce qui est instantané sur mille enregistrements peut être inutilisable sur un million), la MAINTENABILITÉ (pouvez-vous modifier sans tout casser ? un collègue peut-il reprendre ?), la SÉCURITÉ et la facilité de DÉPLOIEMENT. Surveillez les signaux d'alerte : peur de toucher à certaines parties du code, bugs récurrents, corrections qui en provoquent d'autres, règles métier dupliquées et introuvables, utilisateurs qui contournent l'application avec des fichiers parallèles, traitements qui ralentissent, projet que personne d'autre ne peut reprendre. Pour mesurer, écoutez les plaintes récurrentes des utilisateurs (les meilleurs indicateurs), comptez les incidents, observez si le temps nécessaire pour ajouter une fonctionnalité s'allonge — signe de dette technique — et faites relire votre code. Enfin, progressez en continu en traitant les causes plutôt que les symptômes.