Quand développer plutôt qu'acheter
La plupart des besoins trouvent une réponse dans des outils existants, et nous le disons quand c'est le cas. Restent les situations où la chaîne de valeur présente un trou que rien ne comble : un processus vital piloté sur un tableur que deux personnes savent faire fonctionner ; une donnée critique — un délai fournisseur, une température, un stock réel — qui existe dans trois systèmes et n'est juste dans aucun ; une exigence de confidentialité, fréquente dans la défense, incompatible avec les solutions hébergées ; un ERP dont le module manquant coûterait plus cher que l'outil ciblé qui le remplace. Dans ces cas, développer une solution courte et maîtrisée est moins risqué que d'adapter l'organisation à un produit qui n'a pas été pensé pour elle.
Notre critère est simple : le besoin doit toucher au cœur de métier — produire, approvisionner, livrer, tenir en condition — et le coût de l'inaction doit être mesurable. Nous ne développons pas de site vitrine, d'application mobile grand public ni de plateforme générique.
Ce que nous développons — exemples de lots
Chaque exemple ci-dessous correspond à un lot de six à dix semaines, livré par un binôme, dans le périmètre indiqué. Les volumes cités sont des ordres de grandeur.
| Besoin du métier | Ce que nous livrons | Briques | Résultat attendu |
|---|---|---|---|
| Achats — savoir quand un fournisseur de rang 2 met la ligne en danger | Registre des dépendances relié à l'ERP : nomenclatures, fournisseurs, pays, alternatives qualifiées ; alerte sur retard, événement pays ou stock sous seuil | Python, PostgreSQL, connecteur ERP (SAP, Sage, Odoo), tableau de bord web | Chaque composant critique a une source de repli connue ; l'alerte précède la rupture de plusieurs semaines |
| Production — la ligne s'arrête et personne ne sait pourquoi avant le lendemain | Collecte des signaux machines (automates, capteurs), détection de dérive, journal d'arrêts qualifié | OPC-UA / Modbus, séries temporelles, modèles statistiques simples, écran d'atelier | Causes d'arrêt qualifiées en temps réel ; maintenance déclenchée sur dérive, pas sur panne |
| Direction — mesurer l'effet d'un aléa sur un site avant qu'il survienne | Simulateur de scénarios sur vos données : crue, canicule, rupture fournisseur, hausse d'un intrant ; effet sur production, marge, délais | Python, données climatiques (DRIAS, Copernicus), modèle de flux du site | Décisions de protection et de stock arbitrées sur des ordres de grandeur, pas sur des intuitions |
| Qualité, juridique, bureau d'études — retrouver la bonne information dans 40 000 documents | Assistant documentaire local : indexation de vos documents, réponses avec citation de la source, sans qu'aucune donnée ne sorte | Modèles ouverts exécutés sur site (Ollama), RAG, OCR des scans, droits par service | Réponse en secondes avec le passage cité ; documents sensibles jamais envoyés à un tiers |
| Supply chain — des documents fournisseurs saisis à la main | Extraction automatique des bons de livraison, certificats matière, fiches techniques vers l'ERP, avec contrôle croisé et file de vérification humaine | OCR, modèle de vision local, schéma de données forcé, workflow de validation | Saisie divisée par dix ; les seules pièces relues sont celles où les chiffres ne concordent pas |
| Finance — une donnée de marge fausse dans chaque tableau de bord | Entrepôt de données léger consolidant ERP, MES et fichiers métier, avec règles de gestion explicites et tests de cohérence | PostgreSQL, dbt ou SQL versionné, tableaux de bord | Une seule définition de chaque indicateur, vérifiée automatiquement à chaque chargement |
Comment nous travaillons
Un binôme, chez vous
Un développeur et un consultant qui connaît votre métier, présents sur site les jours clés, avec un référent métier désigné de votre côté qui a le droit de dire « ce n'est pas ça ».
Le problème avant l'outil
La première semaine sert à observer le processus réel, mesurer le coût de l'inaction et écrire la « définition du fini » : ce qui, concrètement, sera vrai à la fin du lot et ne l'est pas aujourd'hui.
Une version utilisable chaque semaine
Dès la fin de la première semaine, quelque chose tourne sur vos données réelles. Chaque vendredi, démonstration sur un cas vrai, priorités revues pour la semaine suivante.
Vos données, vos systèmes
Nous nous branchons sur ce qui existe — ERP, MES, automates, fichiers — plutôt que de demander une ressaisie. Les règles de gestion sont écrites en clair et validées par le métier.
Testé, documenté, transféré
Tests automatisés sur les cas métier, documentation d'exploitation, et deux semaines de transfert où vos équipes opèrent et modifient l'outil avec nous à côté.
Un lot, semaine par semaine
Le lot est facturé au forfait sur la définition du fini, pas au temps passé. S'il apparaît en semaine 2 que le besoin est mieux servi par un outil existant, le lot s'arrête et vous ne payez que les deux semaines.
Briques techniques : sobres, ouvertes, reprenables
Nous choisissons les briques pour qu'un développeur qui ne nous connaît pas puisse reprendre l'outil en une journée : Python et SQL pour la logique et les données, PostgreSQL pour le stockage, FastAPI et une interface web légère quand un écran est nécessaire, des connecteurs standard vers vos systèmes — API, OPC-UA, fichiers, bases — et, lorsque de l'intelligence artificielle est utile, des modèles ouverts exécutés sur votre infrastructure, choisis sur des benchmarks publics plutôt que sur des promesses. Pas de framework exotique, pas de service tiers dont l'arrêt arrêterait le vôtre. Le tout tourne sur un serveur chez vous ou, si vous le souhaitez, chez un hébergeur français.
Ce que vous gardez
- Le code et son historique, dans votre dépôt, sous licence libre ou en pleine propriété selon votre choix.
- Les données et leurs règles de gestion, écrites en clair et validées par le métier.
- Les tests qui définissent le comportement attendu et empêchent les régressions.
- La documentation d'exploitation : installer, sauvegarder, mettre à jour, diagnostiquer.
- Des équipes qui savent le faire évoluer, parce qu'elles l'ont fait avec nous pendant le transfert.
Une solution développée pour traiter un besoin vital ne doit pas créer une dépendance nouvelle — ni à un fournisseur, ni à nous.