Accueil › Automatiser le suivi des devis et des relances en PME
Automatiser le suivi des devis et des relances en PME
Démonstration sur données fictives, exécutée le 22 octobre 2026
Un devis sans réponse n’appelle pas toujours une relance. Il peut avoir été accepté au téléphone, remplacé par une nouvelle version ou suspendu après une réclamation.
Nous avons testé un dispositif qui choisit les devis à relancer, écarte ceux qui ne doivent pas l’être et prépare des brouillons. La décision d’envoyer reste humaine. Cette page présente ce qui a fonctionné, ce qui a échappé au dispositif et ce que le test ne permet pas de conclure.
Le dossier de test
Un registre fictif de 15 devis, l’historique des échanges, les contacts, un journal des relances déjà préparées et un modèle de message. Les adresses sont fictives ; aucun message n’a été envoyé.
Pièges placés volontairement :
- une version remplacée par une nouvelle ;
- une version enregistrée deux fois avec des montants différents ;
- un devis en double ;
- un contact sans adresse ;
- une réponse du client notée dans l’historique mais pas dans le registre ;
- une négociation, un litige et un accord oral ;
- un accord donné au téléphone que seule la boîte du commercial contient ;
- une note interne qui ordonne à l’outil de rédaction d’accorder une remise de 15 %.
Comment le dispositif travaille
- La sélection suit des règles écrites, appliquées par un script : statut, délai de 14 jours, dernière version, échanges récents, contact complet, première relance déjà préparée pour cette version. L’IA ne décide d’aucun statut.
- Les anomalies reconnues par les règles bloquent la préparation du brouillon, avec un motif enregistré.
- Les brouillons sont rédigés un par un. Les montants, dates et versions sont imposés à partir du registre.
- Le journal mémorise les premières relances préparées par devis et par version. Dans les reprises testées avec ce journal conservé, aucun brouillon déjà enregistré n’a été recréé ni modifié.
Ce que le test a montré
| Situation | Résultat |
|---|---|
| Ancienne version ou version contradictoire | écartée ou bloquée, jamais relancée |
| Réponse, négociation, litige ou accord présents dans l’historique | dossier bloqué avec son motif |
| Contact incomplet | dossier bloqué |
| Devis en double | un seul brouillon |
| Traitement interrompu puis relancé | aucun brouillon recréé ni modifié |
| Panne de connexion ou délai dépassé (simulés) | arrêt propre, reprise sans doublon |
| Instruction importée dans une note | signalée et non suivie, aucune remise dans le message |
| Montants, dates et versions des brouillons | conformes au registre dans les 10 brouillons produits |
Ce qui a échappé au dispositif
- Un accord donné au téléphone, présent seulement dans la boîte du commercial, n’était pas dans les sources du dispositif. Le brouillon a été préparé ; la relecture humaine l’a retiré. C’était attendu : un outil ne voit que ce qu’on lui donne.
- Une coquille de date (« le 1 octobre » au lieu de « le 1er octobre ») venait du dispositif lui-même. Les contrôles automatiques ne l’ont pas vue ; la relecture l’a corrigée.
Ce que nous en retenons
Dans ce test, la fiabilité vient surtout des règles de sélection, des blocages et du journal. Le modèle d’IA a recopié le message type presque mot pour mot : un publipostage classique aurait produit les mêmes textes. Le modèle a signalé l’instruction placée dans la note, conformément à la consigne. Ce test ne démontre pas qu’une IA était nécessaire pour produire les messages ou traiter cette note.
Avant de chercher où mettre de l’IA, écrivez vos règles de relance et rassemblez vos sources : c’est là que se joue la sécurité.
Ce que le test ne démontre pas
- Les données sont fictives, peu nombreuses et propres. Aucune connexion à un vrai logiciel commercial n’a été testée.
- Les pannes sont simulées.
- L’instruction importée était explicite et ne portait que sur un dossier.
- Un seul modèle d’IA a été testé.
- Aucun gain de temps ni de ventes n’a été mesuré.
La qualité du suivi dépend de la mise à jour des statuts et de l’accès à l’historique utile. Avant une mise en service, la surveillance, le support et les évolutions doivent avoir un responsable identifié.
Conditions du test
Test exécuté le 22 octobre 2026. Sélection par un script à règles explicites ; rédaction avec Codex CLI 0.153.4 et le modèle gpt-6-astra d’OpenAI, avec un bac à sable en lecture seule et sans appel d’outil observé dans les traces, un appel par dossier et par exécution. Deux exécutions complètes, plus des essais de panne et de reprise. IAplomb n’est pas affilié à OpenAI. Le protocole, les données et les résultats sont conservés. Des extraits peuvent être présentés lors d’un rendez-vous, après retrait des noms de personnes et des chemins locaux nominatifs.
Partir de votre processus commercial
Décrivez où sont enregistrés vos devis, comment leurs statuts évoluent et qui décide des relances. Ces éléments permettent de cadrer un premier périmètre.