IA K Studio

D'un problème interne à un produit : comment est né notre outil de suivi des fournisseurs

Nous avions quatre-vingt-quatorze fournisseurs et aucune idée de ceux qui relevaient de l'obligation de vigilance. Voici comment un angle mort administratif est devenu un logiciel.

Le déclencheur

Tout est parti d'une question simple posée en réunion : lesquels de nos fournisseurs sommes-nous censés surveiller ?

Personne n'a su répondre. Pas par négligence, mais parce que la réponse demandait un travail que personne n'avait le temps de faire : reprendre douze mois de factures, additionner par fournisseur, comparer au seuil légal de 5 000 euros hors taxes, et vérifier pour chacun si l'attestation de vigilance URSSAF avait été collectée dans les six derniers mois.

Le risque, lui, était bien réel. L'article L.8222-1 du Code du travail impose au donneur d'ordre de vérifier que ses prestataires sont en règle. En cas de défaillance de l'un d'eux, la responsabilité peut remonter jusqu'à celui qui a payé la prestation. On parle de solidarité financière sur les cotisations impayées.

Nous avions donc une obligation légale, une exposition potentielle, et aucun moyen simple de savoir où nous en étions.

Ce que nous avons découvert en cherchant

Le premier réflexe a été de faire le calcul à la main. C'est là que le problème est devenu concret.

Sur quatre-vingt-quatorze fournisseurs actifs, seuls quatre avaient été formellement identifiés comme soumis à l'obligation. Les quatre-vingt-dix autres n'avaient jamais été tranchés. Pas écartés : jamais examinés. Personne n'avait décidé qu'ils étaient hors périmètre, personne n'avait décidé l'inverse.

Et parmi eux se cachait un cas édifiant : un fournisseur de boissons facturant plus de 900 000 euros sur douze mois. Nous avions longtemps supposé que la vente de marchandises échappait au dispositif. Une vérification juridique nous a détrompés : l'obligation vise l'acte de commerce, pas seulement la prestation de services. Un grossiste au-dessus du seuil est concerné comme n'importe quel prestataire.

C'est le genre de découverte qui donne envie de construire quelque chose.

Du besoin interne au logiciel

La première version n'avait aucune ambition de produit. Il s'agissait de répondre à notre question : qui est concerné, et est-il en règle ?

Trois briques suffisaient. Récupérer les montants facturés par fournisseur depuis la comptabilité, pour calculer automatiquement le cumul sur douze mois glissants. Comparer au seuil légal pour faire remonter les fournisseurs à qualifier. Puis suivre, pour chacun, les pièces à collecter et leurs dates d'expiration.

Ce qui a transformé l'outil interne en produit, c'est la partie que nous n'avions pas anticipée : la collecte. Demander une attestation à un fournisseur, la relancer, vérifier qu'elle est valide, recommencer six mois plus tard, c'est un travail sans fin qui repose sur la vigilance d'une personne. Nous avons donc ajouté un portail où le fournisseur dépose lui-même ses documents, avec des relances automatiques et une détection des dates d'expiration.

À ce moment-là, l'outil ne répondait plus seulement à notre besoin. Il répondait à celui de n'importe quelle entreprise ayant des fournisseurs.

La méthode : partir du réel, livrer vite, corriger avec les utilisateurs

Nous n'avons pas écrit de cahier des charges. Nous avons construit la version qui réglait notre problème du moment, nous l'avons utilisée, et nous avons corrigé ce qui coinçait.

Cette approche a un avantage décisif : les fonctionnalités qui manquent apparaissent d'elles-mêmes, à l'usage. Impossible de les deviner sur le papier. Le portail fournisseur, la détection automatique des dates, la distinction entre un fournisseur jamais qualifié et un fournisseur écarté volontairement : aucune de ces idées n'était dans le plan de départ. Toutes sont venues d'un moment où l'outil ne suffisait pas.

Elle impose aussi une discipline : accepter de livrer quelque chose d'imparfait mais utile, plutôt que d'attendre une version complète qui n'arrive jamais.

Ce que ce projet dit du reste

Cette histoire n'a rien d'exceptionnel. Elle décrit la façon dont naissent la plupart des outils que nous construisons : quelqu'un bloque sur une tâche, on regarde de près ce qu'il fait réellement, et on automatise la partie mécanique.

La différence avec un logiciel acheté sur étagère est là. Un outil né d'un problème vécu connaît les cas particuliers, les exceptions, les moments où la règle générale ne s'applique pas. Il a été corrigé par ceux qui s'en servent, pas conçu par quelqu'un qui n'a jamais eu le problème.

Le suivi de la conformité fournisseurs est devenu un produit à part entière, Prestor. Mais la démarche reste la même pour n'importe quelle corvée administrative : identifier ce qui se répète, comprendre pourquoi c'est pénible, et construire l'outil qui le fait disparaître.

Vous ne savez pas non plus lesquels de vos fournisseurs sont concernés ? Prestor répond à cette question. Et si votre corvée est ailleurs, décrivez-la, on vous dira si elle est automatisable.