Situations
Un ERP vieillissant en est le cas le plus visible. Mais un SaaS fermé, un fichier Excel indispensable ou deux applications modernes qui s'ignorent peuvent geler l'entreprise de la même façon.
Le problème n'est pas le legacy. C'est ce qu'on ne peut plus faire avec lui.
Trop critique. Trop cher. Trop risqué. Le projet attend.
Chaque changement peut casser un métier — et le schéma ne vous appartient pas.
Données dispersées, verrouillées, hétérogènes. L'admin dit non, souvent à raison.
Situations types
Exemples illustratifs — ni les entreprises ni les chiffres ne sont ceux d'un client. Le déclencheur est souvent le même : un expert qui part, un rachat, ou un dossier qui dort trop longtemps.
Quatre usines, quatre ERP différents (Sage X3, Divalto, un développement maison). Quand une ligne s'arrête, la maintenance téléphone aux sites voisins — et une ligne arrêtée coûte quatre chiffres de l'heure.
Une pièce, une fiche fusionnée, une question — la réponse site par site en quelques secondes. Un seul arrêt évité peut payer des années d'outil.
L'acquéreur découvre 40 % de références en doublon entre son Sage et l'EBP racheté. Les commerciaux annoncent des prix différents pour le même article.
La fiche produit unique est servie en quelques semaines, pendant que la migration avance à son rythme. Le registre des conflits EST la liste de dédoublonnage que l'équipe attendait.
Envoyé un vendredi, marqué « en attente » — puis plus rien. Le commercial est sur la route, le statut n'a pas bougé depuis six semaines, et aucun système n'alerte sur ce qui ne se passe pas. Le client a signé ailleurs.
lumnik observe chaque dossier, lecture après lecture, et signale l'immobile au-delà du seuil que vous avez déclaré, avec la date de sa première observation. Il ne reste qu'à décrocher le téléphone.
Un système déclassé en 2019, conservé uniquement parce que la loi impose de garder ses données dix ans. Licence + serveur + le seul admin qui sait le redémarrer : cinq chiffres par an pour une poignée de consultations.
Une dernière ingestion, puis la machine s'éteint. L'archive reste interrogeable après l'arrêt de l'ancien système. Le retour sur investissement est une soustraction qu'on fait de tête.
Les petites communes n'auront jamais le budget d'un tel outil chacune. Un syndicat ou un intégrateur public en opère un seul — chaque commune ne voit que sa tranche, isolation appliquée par la base elle-même.
L'architecture multi-organisations n'est pas de la plomberie : c'est le produit. Un déploiement, cinquante dégels.
Le mouvement retrouvé
Un agenda, un tableau de bord ou un moteur de règles attend un signal exploitable. Beaucoup de systèmes — anciens ou fermés — n'en produisent aucun.
lumnik observe, compare et date : chaque changement devient un événement consommable par Make, n8n, Power Automate, un simple email à l'équipe, un export ou une requête SQL. Et chaque silence aussi : « immobile depuis trente jours » est une alerte que la source n'aurait jamais émise.
Pas de webhook, pas d'historique, pas de flux exploitable.
Chaque ingestion produit un changement détectable, ou une immobilité constatable.
Webhook, email, SQL, tableau de bord, moteur de règles, agenda partagé.
X-Lumnik-Event: decision.dormant.acme-order-lifecycle
{
"message": "SO-000006 : observé immobile en « EN LITIGE » depuis le 2026-09-13 (première observation 2026-09-13) — seuil déclaré 1m dans acme-order-lifecycle",
"workflow": "acme-order-lifecycle",
"doc_key": "SO-000006",
"state": "EN LITIGE",
"since": "2026-09-13T00:45:00Z",
"first_observed_at": "2026-09-13T00:45:00Z",
"threshold": "1m"
}
Sa forme exacte, sur les données de démonstration — seuil raccourci à une minute.
Zéro accès au legacy pour vos outils modernes.
Un seul endroit à reprendre le jour où l'ERP change.
Enfin des courbes même quand la source n'a gardé que l'état courant.
Vos données deviennent une API — chaque entité fusionnée est lisible par vos propres outils, en lecture seule.
Ces événements battent au rythme de la respiration — l'heure, pas la milliseconde. Assez vite pour un agenda, un tableau de bord ou une alerte métier. Et rien, jamais, n'écrit vers la source.
Pour situer
| L'alternative classique | Ce qu'elle exige | lumnik |
|---|---|---|
| Le projet BI / entrepôt de données | 6 à 18 mois, une équipe data, des consultants, un budget à six chiffres | Premier périmètre interrogeable en quelques semaines, sans équipe data entre le métier et la réponse |
| La migration d'ERP | Des années, un risque majeur, et l'historique reste souvent derrière | Sert les métiers maintenant — et devient l'instrument de la migration si elle a lieu un jour |
| « Une IA branchée sur vos données » | Des réponses plausibles… et personne pour garantir qu'elles sont vraies | Des garde-fous : requête exécutée affichée, périmètres bornés, refus déterministes plutôt qu'invention |
| L'interface payante de l'éditeur historique | Cinq chiffres par connecteur, et un ticket de trois mois pour chaque rapport | Une fois ingéré, le même socle sert le chat, l'API et les tableaux — deux besoins, une ingestion |