# Chiffrer les tests automatisés dans un devis client sans exploser le budget

> Une méthode pour estimer et présenter le poste des tests automatisés dans une offre commerciale, sans qu'il paraisse superflu ni qu'il fasse fuir le client sur le montant total.

- Auteur : WordPress Développement
- Publié le : 2024-03-26
- Mis à jour le : 2024-03-26
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/chiffrer-tests-automatises-devis-client/

## L’essentiel

- Chiffrer les tests comme une ligne distincte, jamais noyée dans le développement
- Justifier le poste par le risque évité, pas par principe
- Proposer un niveau de couverture modulable selon le budget disponible

15 à 20 % du temps de développement total : c'est la fourchette qu'un freelance spécialisé en extensions WordPress sur mesure a fini par retenir pour chiffrer les tests automatisés dans ses devis, après plusieurs projets où ce poste, absent du chiffrage initial, avait été sacrifié en cours de route faute de budget restant.

Le problème n'est pas seulement de trouver le bon pourcentage : c'est de le présenter au client de façon à ce qu'il comprenne pourquoi ce poste existe, plutôt que de le percevoir comme une ligne technique abstraite qui gonfle la facture sans bénéfice visible pour lui.

## Pourquoi les tests disparaissent des devis

Un devis qui ne détaille pas le poste des tests laisse le client penser qu'ils sont inclus gratuitement dans le développement, ou qu'ils n'existent tout simplement pas. Quand le budget se resserre en cours de projet, ce qui n'est pas nommé explicitement est ce qui saute en premier, parce que rien ne permet au client de mesurer ce qu'il perd en le retirant.

## Une checklist pour chiffrer ce poste correctement

> L'essentiel à retenir : Chiffrer les tests comme une ligne distincte, jamais noyée dans le développement ; Justifier le poste par le risque évité, pas par principe ; Proposer un niveau de couverture modulable selon le budget disponible

1. **Isoler le poste dans le devis**, sous une ligne intitulée « Fiabilisation et tests automatisés », distincte de « Développement des fonctionnalités », avec son propre nombre d'heures et son propre montant.
2. **Chiffrer en fonction du risque métier**, pas en pourcentage fixe uniforme : une fonctionnalité de paiement ou de gestion de données personnelles justifie une part de tests plus élevée qu'une page vitrine statique.
3. **Proposer trois niveaux** (essentiel, standard, renforcé) avec pour chacun une description concrète de ce qui est couvert, pour que le client arbitre en connaissance de cause plutôt que de subir un chiffre unique non négociable.
4. **Documenter ce qui n'est pas couvert** au niveau choisi, dans une clause explicite du devis, pour éviter tout malentendu ultérieur sur le périmètre réellement testé.

### Un exemple de présentation retenue

| Niveau | Ce qui est couvert | Part du budget développement |
| --- | --- | --- |
| Essentiel | Tests sur les fonctions de calcul et de paiement uniquement | 8 à 10 % |
| Standard | Essentiel + parcours utilisateur principaux en test de bout en bout | 15 à 20 % |
| Renforcé | Standard + cas limites documentés + intégration continue avec matrice de compatibilité | 25 à 30 % |

## Justifier le poste par le risque évité, pas par principe

Face à un client qui questionne ce poste, l'argument le plus efficace n'est pas une conviction générale sur la qualité logicielle, mais un exemple chiffré et concret : le coût d'un bug de calcul de remise découvert après mise en ligne (support client, correctif en urgence, image dégradée) dépasse presque toujours le coût des tests qui l'auraient évité. Présenter ce comparatif, avec un exemple réel d'un projet précédent quand c'est possible, convainc davantage qu'un discours théorique.

> Un client qui comprend ce que les tests évitent négocie rarement leur suppression ; un client à qui on ne l'a jamais expliqué le fait presque toujours.

## Ce qu'il faut éviter dans la présentation

- Noyer les tests dans une ligne générique « qualité et bonnes pratiques », trop vague pour être défendue si le client cherche à réduire le budget.
- Promettre un taux de couverture chiffré précis sans expliquer ce que ce chiffre recouvre réellement : la négociation d'un taux contractuel est un sujet distinct, à part entière.
- Proposer un seul niveau non négociable : sans alternative, le client qui doit réduire le budget retire le poste entier plutôt qu'un sous-ensemble.

### Réagir quand le client négocie ce poste à la baisse

Face à une demande de réduction, la meilleure réponse n'est pas de baisser le pourcentage sur toutes les fonctionnalités uniformément, mais de proposer de redescendre d'un niveau uniquement sur les parties à faible risque, en conservant le niveau essentiel sur les fonctions de paiement ou de données personnelles. Cette négociation ciblée, plutôt qu'une remise générale, préserve l'essentiel du poste tout en donnant satisfaction au client sur le montant global du devis.

## En résumé

Isoler le poste des tests, le chiffrer selon le risque réel de chaque fonctionnalité et proposer plusieurs niveaux modulables transforme une ligne technique abstraite en un choix éclairé pour le client. Sur les devis suivant cette méthode, le poste des tests a été conservé dans la quasi-totalité des projets signés, contre un abandon fréquent lorsqu'il figurait de façon implicite dans le forfait de développement.