Quand un outil fait tout… sauf ce dont vous avez besoin

Cet article est le deuxième d’une série qui documente la construction d’un système d’automatisation de la prospection B2B, renforcé par l’IA. Le premier article posait le contexte : comment identifier la bonne source de données pour constituer une liste de prospects qualifiés. Celui-ci documente l’étape suivante : une fois le pipeline en place et fonctionnel, pourquoi l’avoir entièrement réécrit.

Le sujet réel n’est pas technique, c’est la différence entre un outil qui tourne et un outil qu’on maîtrise. Une distinction qui concerne autant un système d’automatisation qu’un tableau de bord, un outil de facturation ou n’importe quelle brique informatique sur laquelle une activité repose.

Le point de départ : un pipeline fonctionnel mais opaque

Au moment où cette migration a été décidée, le pipeline existant faisait son travail. Trois séquences automatisées s’enchaînaient chaque semaine : une collecte depuis le registre légal des entreprises avec préfiltrage sur les critères de ciblage définis, un enrichissement par l’agent IA pour qualifier chaque prospect (site web, score de pertinence, contact dirigeant) puis un push vers le CRM pour alimenter le pipeline commercial. Rien de tout ça ne demandait d’intervention manuelle.

Le problème n’était pas que ça ne fonctionnait pas mais que personne ne pouvait répondre à des questions pourtant simples : combien de prospects avaient été collectés la semaine passée ? L’enrichissement s’était-il bien terminé ou s’était-il arrêté en cours de route ? Le filtre géographique avait-il écarté des entreprises qui auraient dû passer ou au contraire inclus des entreprises hors zone ? La réponse à chacune de ces questions était “je ne sais pas” et la seule façon de le vérifier était d’aller inspecter le CRM manuellement.

Ce qui existait était donc un pipeline fonctionnel mais opaque, avec une logique métier répartie dans des blocs visuels que personne n’osait vraiment modifier. Chaque évolution envisagée déclenchait la même question : est-ce que je risque de casser quelque chose sans m’en rendre compte ?

Ce qu’on a trouvé en creusant

Problème 1 : Aucune traçabilité des exécutions.

Chaque semaine, le système tournait mais ne produisait aucun rapport d’exécution consultable : pas de comptage des prospects collectés, pas d’indication sur les étapes qui avaient abouti ou échoué, pas d’historique auquel revenir en cas de doute. L’outil d’automatisation visuel signale les erreurs bloquantes, il ne garde pas de trace de ce qui s’est bien passé. La conséquence directe : impossible de détecter une dégradation silencieuse du pipeline (une baisse du nombre de prospects collectés, par exemple) sans aller vérifier manuellement dans le CRM à chaque fin de semaine. Le pilotage du système reposait entièrement sur une vérification humaine ponctuelle ce qui annulait une partie du bénéfice de l’automatisation.

Problème 2 : Le filtre géographique restait binaire, donc imprécis.

La cible géographique définie pour ce projet n’est pas “tous les entreprises de Normandie”, c’est “les entreprises dont le siège est à moins de X kilomètres d’un point de référence”. Cette distinction a une conséquence concrète : un département entier contient des zones très éloignées du centre d’activité et des entreprises pertinentes se trouvent de l’autre côté d’une frontière départementale. Calculer une distance réelle entre deux coordonnées géographiques nécessite une formule mathématique. L’outil d’automatisation visuel ne peut pas l’exécuter. Le filtre restait donc au niveau du département : soit trop large (du bruit dans le pipeline), soit trop restrictif (des prospects pertinents exclus). Ce n’était pas un problème de paramétrage mais une limite structurelle de l’environnement.

Avec du recul : ce qu’on aurait fait autrement

La décision de migrer vers une application sur mesure n’a pas été prise à la légère car elle représentait plusieurs jours de développement pour remplacer un système qui fonctionnait. Ce qui l’a rendue inévitable, c’est la convergence de deux constats : d’abord, les limitations identifiées n’étaient pas contournables dans l’environnement existant ; ensuite, toute évolution future du pipeline se heurterait aux mêmes obstacles.

La synthèse qui s’impose : les outils d’automatisation visuels sont le bon choix pour démarrer vite, automatiser des enchaînements simples et tester une idée sans développement. Leur limite apparaît quand la logique métier gagne en complexité, la traçabilité devient nécessaire au pilotage ou, signal le plus fiable, quand on hésite à faire évoluer le système parce qu’on a peur de le casser. À ce stade, l’outil ne sert plus l’activité : c’est l’activité qui s’adapte à l’outil.

Ce que ça change concrètement

L’application sur mesure qui a remplacé le pipeline visuel apporte quatre choses que l’outil précédent ne pouvait pas fournir : un historique des exécutions consultable à tout moment, un filtre géographique précis avec une carte de validation visuelle, une configuration entièrement modifiable sans toucher au code et un scheduling reprogrammable sans redémarrage du service.

La généralisation qui s’impose dépasse le cas de la prospection. Dans une PME, la question décisive sur n’importe quel outil d’automatisation n’est pas “est-ce que ça tourne ?” mais “est-ce que je peux comprendre ce qu’il a fait et le faire évoluer sans risque ?” Un outil qu’on n’ose plus modifier est un outil qui gouverne à la place de ceux qui sont censés le piloter. Cette dépendance inversée est un risque opérationnel réel, même quand le service rendu reste satisfaisant.

Un outil qui tourne n’est pas un outil qu’on maîtrise

La distinction mérite d’être posée clairement, parce qu’elle est rarement formulée comme telle : un système fonctionnel et un système maîtrisé ne sont pas la même chose. Le premier produit un résultat. Le second produit un résultat qu’on peut observer, expliquer, modifier et transmettre à quelqu’un d’autre sans que tout s’effondre.

Si vous avez des automatisations en place depuis plusieurs mois et que vous seriez incapable d’expliquer précisément ce qu’elles ont fait la semaine passée, la question vaut la peine d’être posée (avant qu’une évolution nécessaire ou un incident vous y oblige).

La suite logique de ce projet, confier le développement de la nouvelle version entièrement à l’IA, fait l’objet du prochain article. L’expérience a été plus instructive que prévu.