LINQA : De Supplier Performance Manager à co-fondateur d'un SaaS de pilotage fournisseurs

Dix ans dans la défense et l'aéronautique. Dix ans à piloter la performance de fournisseurs critiques, dans des environnements où un seul retard de livraison peut mettre à l'arrêt une chaîne de production complète.

Et malgré ça ? La routine ne bougeait pas. On ouvrait un fichier Excel partagé le lundi matin, on croisait tant bien que mal les données de l'ERP avec les remontées qualité, on bricolait un calcul d'OTD à coups de macros, et on finissait par copier-coller les indicateurs dans un PowerPoint pour que la revue fournisseurs ait l'air à peu près propre.

Les données étaient là. Éparpillées entre tableurs, boîtes mail et logiciels qui s'ignoraient royalement. Ce n'est pas l'information qui manquait. C'est un lieu unique pour la transformer en quelque chose d'actionnable. Un outil pensé pour le terrain, pas pour la salle de réunion.

Pour les PME et ETI que j'accompagnais, c'était pire. Qui, dans une boîte de 200 personnes, a le temps de jouer les data analysts entre deux urgences de production ?

LINQA est née de cette accumulation de frustrations silencieuses.

L'envie d'entreprendre, je l'avais depuis longtemps, planquée dans un coin de ma tête. LINQA a été le déclic.

Avec mon associé, qui amène une vraie patte commerciale et une expérience entrepreneuriale solide, on a commencé par valider l'intuition. Interviews utilisateurs. Étude de marché. Les classiques, mais faits sérieusement.

Et les chiffres nous ont confortés : le segment SRM/QMS pour les PME-ETI industrielles pèse 3,66 milliards d'euros en Europe. Porté par la réindustrialisation, tiré par des filières exigeantes (aéro, défense, pharma, énergie) qui ne peuvent plus se permettre de bricoler leur traçabilité.

Dans ce duo, la répartition des rôles s'est faite naturellement. Mon parcours terrain, couplé à un appétit grandissant pour la tech, me plaçait côté produit et technique. Mon titre de CPTO (Chief Product and Technology Officer) résume bien ce que je préfère faire : comprendre très précisément ce que le produit doit résoudre, puis le coder moi-même.

Concrètement, LINQA remplace les tableurs par un cockpit modulaire et prédictif. Cinq modules métier, chacun taillé pour un irritant précis :

• Performance : le tableau de bord global. KPI supply chain (OTD, OQD, PPM), tendances mensuelles, seuils d'alerte, score consolidé. La vue que tout directeur supply chain rêve d'ouvrir le lundi matin • Logistique : commandes en cours, retards, backlog. Filtrage fin par opérateur, date, quantité, parce qu'un retard sans contexte, ça ne sert à rien • Qualité : non-conformités et dérogations, avec un vrai workflow (ouverture → analyse → clôture), badges de sévérité et historique complet • Plans d'action : actions correctives rattachées aux incidents qualité. Le suivi qui transforme un problème ponctuel en amélioration durable • LINQAI : la couche IA qui digère les données en temps réel pour générer des recommandations priorisées et des alertes contextuelles

Chaque entreprise (tenant) vit dans un espace hermétiquement cloisonné. Responsable qualité, acheteur, directeur supply chain : tout le monde utilise le même outil, chacun avec ses permissions.

Les gains attendus ? 50% de productivité en plus sur le reporting et le suivi, 10% de réduction sur les coûts supply chain. Mais le vrai basculement, c'est ailleurs : passer d'une gestion qui éteint des feux à une gestion qui les anticipe.

Pas de choix techno pour le plaisir. Chaque brique de la stack répond à une contrainte business bien réelle.

1. Un seul dev au départ, moi (épaulé par Claude Code). Il me fallait livrer vite sans sacrifier la qualité. Next.js 16 avec l'App Router et les Server Components de React 19 : frontend, backend et API dans un seul dépôt. Monter des microservices à ce stade ? Absurde.

2. Multi-tenant dès le premier jour. Pas question de greffer l'isolation des données après coup. C'est le genre de dette technique qui finit toujours par exploser. Supabase (PostgreSQL) avec Row Level Security garantit nativement, à chaque requête SQL, que chaque client ne voit que ses propres données.

3. Un produit qui inspire confiance au premier clic. Dans l'industrie, la première impression lors d'une démo est décisive. L'interface s'appuie sur shadcn/ui et Tailwind CSS v4, dans l'esprit des standards posés par Stripe et Linear. Typographie soignée, espacement rigoureux, micro-interactions, composants Radix UI accessibles.

Côté dataviz, c'est Recharts qui fait le travail : histogrammes de retard moyen, courbes OTD sur 6 mois glissants, graphiques de volume de livraison.

Quand on fabrique un SaaS pour des PME de la défense, de l'énergie ou de l'aéro, un prérequis écrase tous les autres : la confidentialité. Point final. Qu'une donnée sur la performance d'un sous-traitant critique fuite, et c'est la crédibilité du produit, et la nôtre, qui s'effondre.

Tout le socle de LINQA repose donc sur quelque chose d'invisible mais fondamental : l'isolation des tenants.

J'aurais pu coder des filtres manuels à chaque page, à chaque requête. Beaucoup le font. Mais cette approche a un défaut structurel : elle dépend de la rigueur humaine. Et l'humain, il oublie un filtre à 23h un vendredi soir.

Alors j'ai poussé toute la logique de sécurité au niveau le plus bas possible : directement dans PostgreSQL, via Row Level Security. La base de données elle-même agit comme garde-fou. Chaque requête porte un contexte strict. Si ce contexte ne colle pas aux données demandées, l'accès est refusé à la source. Pas au niveau de l'application, pas au niveau de l'API. À la source.

Cette ségrégation architecturale est ce qui fait la différence entre une app web et une vraie plateforme industrielle.

L'IA dans LINQA, ce n'était pas un buzzword plaqué sur la plaquette. C'était le cœur du différenciant produit.

Pourquoi ? Dans la supply chain, collecter les données n'est pas le problème. Les lire, les comprendre, les croiser, ça, c'est une autre paire de manches. Un retard moyen qui grimpe de 2% par mois sur un fournisseur, un OTD qui glisse doucement pendant trois mois d'affilée. Ce sont des signaux faibles. Quand on pilote 50 fournisseurs, ces micro-dérives passent sous le radar. L'IA devait attraper ce que l'œil humain laisse filer.

Le module était pensé contextuel, pas générique : • Dashboard global → synthèse consolidée des risques • Fiche fournisseur → recommandations ciblées, ancrées dans l'historique du fournisseur • Module qualité → détection de tendances récurrentes sur les non-conformités

Sous le capot, l'architecture suivait le même patron que le reste de l'app. Un composant serveur qui récupère les données, un composant client qui les affiche. La seule différence : entre les deux, une couche d'analyse qui détecte les anomalies et hiérarchise les actions à mener.

Six mois de développement intensif. Un MVP quasi-fonctionnel au bout du tunnel. Mais pas le module IA. La recherche de financement n'a pas abouti.

Sans cette levée, impossible de sécuriser la plateforme sur la durée ni de développer la brique qui devait porter le différenciant. On a pris la décision, difficile mais lucide, d'arrêter l'aventure entrepreneuriale.

Je n'ai aucun regret. Et je reste profondément convaincu qu'un outil comme celui-ci manque aux industriels.