Des modèles qui tiennent
en conditions réelles.
La plupart des modèles ne survivent pas au passage en production : données qui dérivent, latence, utilisateurs qui contournent l'outil. Nous concevons chaque modèle pour ce moment-là — pas pour la démo qui le précède.
Le modèle n'est pas le projet.
Le système autour, si.
Un bon modèle qui n'est pas intégré, pas surveillé et pas adopté ne produit rien. Ce qui fait la différence en production tient en quatre points — et aucun n'est un problème de data science.
Les données bougent
Un modèle entraîné sur l'an dernier se dégrade silencieusement. Sans détection de dérive ni ré-entraînement prévu dès la conception, la performance s'érode sans que personne ne le voie.
La décision a un coût
Optimiser la précision d'un modèle n'a aucun sens en soi. Ce qui compte, c'est le coût réel d'une erreur — et il n'est jamais symétrique. Nous calibrons sur vos coûts, pas sur une métrique académique.
L'intégration décide de tout
Un score qui arrive trop tard, ou dans un outil que personne n'ouvre, ne sert à rien. Le modèle doit arriver là où la décision se prend, au moment où elle se prend.
La confiance se construit
Vos équipes doivent comprendre pourquoi le modèle recommande ce qu'il recommande. Explicabilité, garde-fous et validation humaine là où l'enjeu le justifie.
Un moteur de décision temps réel
calibré sur les coûts réels.
Un acteur du e-commerce en paiement à la livraison, avec des coûts logistiques élevés à chaque refus ou non-retrait de colis. Les règles statiques en place ne distinguaient plus les commandes à risque des autres.
Conception d'un moteur de scoring prédictif intégrant des signaux comportementaux, techniques et géographiques. Décision orientée coût attendu — pas simple probabilité — et déployée en temps réel dans le tunnel de commande.
Réduction des pertes logistiques et moteur adaptable : les seuils de décision se réajustent quand les coûts ou les volumes changent, sans reconstruire le système.
Du cadrage du problème
au modèle surveillé en production.
Cadrage et faisabilité
Traduction du problème métier en problème modélisable, audit des données disponibles, estimation honnête de ce qui est atteignable. Nous vous disons quand le machine learning n'est pas la bonne réponse.
Modélisation
Scoring, classification, prédiction, détection d'anomalies, prévision de séries temporelles. Le modèle le plus simple qui atteint l'objectif — la complexité se paie en production.
Industrialisation
Déploiement, API temps réel ou traitement par lots, intégration dans vos outils existants, tests et reproductibilité. Ce qui transforme un notebook en système.
Surveillance et durée de vie
Détection de dérive des données et de la performance, alertes, procédure de ré-entraînement. Un modèle est un système vivant, pas un livrable figé.
Trois phases,
avec une sortie possible à chaque étape.
Cadrage et faisabilité
Analyse des données réelles, définition de la métrique de succès en termes métier, prototype rapide. Livrable : un go/no-go argumenté. Si les données ne permettent pas, nous le disons ici.
Modèle et validation
Construction itérative, validation sur données réelles et sur la période récente. Le modèle est confronté aux cas difficiles, pas seulement à la moyenne.
Mise en production
Déploiement, intégration, surveillance, documentation et transfert. Vos équipes savent lire les alertes et déclencher un ré-entraînement.
Combien de données faut-il ?
Cela dépend entièrement du problème : quelques milliers de cas bien étiquetés valent mieux que des millions de lignes bruitées. Le cadrage initial répond précisément à cette question avant tout engagement.
Et si nos données ne sont pas propres ?
C'est la situation normale, pas l'exception. La préparation et la qualité des données représentent l'essentiel du travail réel — nous les traitons comme une partie du projet, pas comme un prérequis à votre charge.
Faut-il une équipe data en interne ?
Non pour démarrer. Mais nous concevons pour le transfert : documentation, formation et procédures pour que vos équipes reprennent la main. Si vous n'avez pas d'équipe, nous pouvons assurer le maintien en conditions opérationnelles.
Peut-on démarrer petit ?
C'est même recommandé. Un premier périmètre restreint mis en production apprend davantage — et engage moins — qu'un grand projet qui reste en phase d'étude.
Un problème de décision à automatiser ?
Trente minutes avec un ingénieur pour dire si le machine learning est la bonne réponse — ou pas. Sans engagement.