Hábil MDW

Vos systèmes, enfin d'accord.

Votre système central, votre ERP et vos canaux connectés sans les remplacer, avec la trace de chaque opération.

La plateforme qui connecte vos systèmes.

Parlons de votre cas

Vous préférez l'e-mail ? Écrivez-nous à hola@habil.mx

Qu'est-ce que Hábil MDW ?

Hábil MDW, l'Enterprise Middleware Platform de Hábil, est la couche qui se place entre les systèmes que vous avez déjà. Par elle passent chaque commande, chaque encaissement, chaque police et chaque notification, avec la réponse de celui qui l'a reçu et le motif si quelque chose a échoué.

Vos systèmes fonctionnent ; ce qui se perd se trouve entre eux. Un paiement parti du canal qui n'est pas arrivé en comptabilité. Une police émise que le CRM ne connaît pas. Une commande que le magasin a encaissée et que l'entrepôt n'a pas vue. Chaque système dit que tout va bien, et l'écart, c'est votre équipe qui l'absorbe, avec des feuilles de calcul et des appels, à la clôture du mois. Quand les connexions se multiplient sans carte, le travail manuel devient partie intégrante de l'activité, et changer un système devient impensable, parce que personne ne sait ce qui va casser.

Hábil MDW met de l'ordre dans cet espace. Il se connecte à votre système central, à votre ERP et à vos canaux par les voies que chacun possède déjà, convertit ce qui arrive dans un même langage, fait passer chaque opération par les étapes que votre activité définit et enregistre ce qui s'est passé, quand et qui l'a fait. Vos systèmes continuent de faire ce qu'ils font ; Hábil MDW veille à ce qu'ils se comprennent.

C'est une plateforme propre à chaque client : vos opérations ne partagent leur installation avec celles de personne d'autre. Il fonctionne sur votre infrastructure ou sur la nôtre, l'exploitation étant assurée par Hábil. Et il se contracte séparément de Hábil AI et de Hábil Lake : vous pouvez utiliser l'un sans les autres.

Trois niveaux, selon vos besoins

Hábil MDW est un produit et un service. Le produit, c'est la plateforme. Le service, c'est ce que nous faisons avec vous pour que vos systèmes travaillent comme un seul. Il se contracte par niveaux, et chacun s'appuie sur le précédent.

La plateforme

Vos systèmes connectés, avec la trace

Ce que vous obtenez avec le produit :

  • Une installation rien que pour vous, sur votre infrastructure ou sur la nôtre, opérée par Hábil.
  • La connexion avec ce que vous avez déjà. Votre système central, votre ERP, votre boutique en ligne, vos canaux de service client et vos partenaires, par les voies que chaque système offre déjà.
  • Un même langage pour tous. Chaque système entre avec sa propre forme, et la plateforme le traduit dans un modèle commun : une commande est une commande, d'où qu'elle vienne.
  • Les étapes de votre activité, en configuration. Ce qui se passe après l'encaissement, qui est prévenu, ce qui est facturé : cela se définit en configuration, pas dans le code.
  • Une porte d'entrée gardée pour vos partenaires. Banques, magasins, agents et distributeurs se connectent avec leur propre identité et leurs propres permissions.
  • La trace de chaque opération. Ce qui a été envoyé, ce que chaque système a répondu, à quelle heure et, en cas d'échec, pourquoi.
  • Sans licences d'entreprise payantes. Nous utilisons des composants ouverts ou d'usage libre.

Pour démarrer

Votre premier flux, de bout en bout

Nous connectons les systèmes d'un premier flux complet — par exemple, de la commande à l'encaissement et à la facture —, définissons avec vous les étapes et les règles, et le laissons en marche avec la trace à la vue de votre équipe.

À ce niveau, nous choisissons ensemble le flux qui se bloque le plus aujourd'hui ou qui coûte le plus de travail manuel. Pour ce flux, nous mettons par écrit quel système fait chaque étape, ce qu'on lui envoie, ce qu'il doit répondre et ce qui se passe s'il ne répond pas. À la fin, ce flux passe par la plateforme, et l'ancienne connexion n'est coupée que lorsque la nouvelle a démontré qu'elle concorde.

Pour aller plus loin

Plus de flux, canaux et partenaires

Nous ajoutons des flux, des canaux et des partenaires, avec des alertes, des tableaux de bord d'exploitation et la cohabitation par étapes avec les systèmes qui vont être remplacés.

Ce niveau est pour le moment où la plateforme est déjà le chemin par lequel passe l'activité et où d'autres fonctions veulent l'utiliser. Nous ouvrons la porte à de nouveaux partenaires, ajoutons des canaux de service client, ramenons dans le même lit les anciennes connexions que personne ne veut toucher et, si vous le décidez, connectons vos opérations à Hábil Lake et à Hábil AI.

Reconnaissez votre fonction

Direction et Finance« Chaque système concorde tout seul ; ensemble, non. À la clôture, quelqu'un rapproche à la main ce que dit le système central et ce que la banque a encaissé. »Chaque opération passe par un même chemin, avec sa réponse et son heure, et ce qui n'est pas arrivé se voit le jour même, pas à la clôture
Opérations« Nous ne savons pas si cette opération est arrivée. On relance à la main, et parfois elle est dupliquée. »Chaque envoi reste avec sa réponse ou son motif d'échec, et les relances sont conçues pour ne pas répéter l'effet
Commercial« Nos partenaires veulent vendre depuis leur système, et nous leur envoyons des fichiers par e-mail. »Une porte pour vos partenaires, avec leur identité, leurs permissions et leur propre trace, pour qu'ils puissent coter, émettre ou encaisser de leur côté
Technologie (DSI / CTO)« Si nous changeons ce système, tout le reste tombe, et une seule personne sait comment ils sont connectés. »Les connexions cessent de vivre à l'intérieur de chaque système et passent dans une couche avec une carte et une trace ; le détail figure plus bas
Conformité« L'auditeur demande des preuves, et nous les cherchons dans des e-mails et des journaux épars. »Chaque opération enregistrée avec sa réponse, son heure et qui l'a faite, et les données personnelles masquées dans les journaux

Là où Hábil MDW apporte de la valeur

Huit scénarios. Ce sont des scénarios, pas des clients : ils montrent le type de problème que Hábil MDW résout, comment il le fait et quelles capacités il utilise.

Scénario : des tarifs qui changent sans projet informatique · Assurance automobile et dommages

Avant : la prime change selon la garantie, la zone, la franchise, le capital assuré, l'âge, la durée et le canal. Avec un système sur mesure, chaque ajustement de tarif ou de règle est un projet informatique, et le canal des agents attend des semaines.

Ce qui change : votre compagnie d'assurance ou votre canal d'agents cote, émet, encaisse et facture des polices avec ses règles et ses tarifs. Un ajustement de tarif relève de la configuration, et il arrive de la même façon à tous les canaux que vous connectez : le web, les agents et les partenaires.

Pourquoi c'est difficile : le tarif vit dans le système central, l'encaissement dans un autre système et la facture dans un troisième, et les trois doivent raconter la même police.

Comment Hábil MDW le résout : les règles et les étapes de la police se définissent en configuration, et la plateforme conduit chaque police du système central à l'encaissement et à la facture, avec la réponse de chaque système en vue.

Capacités : Connecter vos systèmes · Les étapes de votre activité · Porte d'entrée gardée.

Scénario : l'accord avec un partenaire, sans le gérer à la main · Assurance collective, affinitaire et extensions de garantie

Avant : un accord avec un partenaire ou une extension de garantie est un plan avec des règles, des arrêtés, un encaissement et des réclamations, géré à la main ou dans un développement dédié à ce partenaire.

Ce qui change : l'émission par lots, le prélèvement des encaissements, le dossier, la réclamation et le rapport au partenaire suivent un même chemin. Le partenaire consulte depuis son système ce qui le concerne, avec sa propre identité.

Pourquoi c'est difficile : chaque partenaire envoie ses fichiers avec son format et ses arrêtés, et le rapport en retour doit concorder avec ce qui a été encaissé.

Comment Hábil MDW le résout : les fichiers de chaque partenaire sont traduits dans le même langage, chaque lot laisse sa trace et le partenaire entre par la porte d'entrée gardée, avec des permissions limitées à ce qui le concerne.

Capacités : Connecter vos systèmes · Les étapes de votre activité · Porte d'entrée gardée · Opérer 24/7 avec traçabilité.

Scénario : le réseau de santé, sur un même chemin · Santé : contrats collectifs et réseaux de soins

Avant : catalogues, cabinets, carte digitale, agenda et consentement vivent entre des feuilles de calcul et des systèmes qui ne se parlent pas. Un rendez-vous se chevauche avec un autre et un consentement se perd.

Ce qui change : le devis, la carte, un agenda qui évite les chevauchements, l'encaissement et la preuve du consentement passent par la même plateforme. Chaque cabinet du réseau voit ce qui le concerne.

Pourquoi c'est difficile : les données de santé exigent une attention particulière, et chaque cabinet utilise son propre système, ou aucun.

Comment Hábil MDW le résout : la plateforme connecte chaque cabinet par la voie dont il dispose, conserve la preuve de chaque consentement et laisse les données personnelles masquées dans les journaux.

Capacités : Connecter vos systèmes · Les étapes de votre activité · Opérer 24/7 avec traçabilité.

Scénario : du simulateur au recouvrement · Crédit, sociétés financières et retraites

Avant : la mensualité change selon l'apport, la durée, le profil de risque, l'assurance incluse et la campagne ; le calcul de la retraite est une formule complexe. Ensuite, il faut approuver et encaisser, dans d'autres systèmes.

Ce qui change : le simulateur, l'approbation et le recouvrement suivent un même flux, et la formule relève de la configuration. Un changement de campagne se configure une fois pour tous les canaux connectés.

Pourquoi c'est difficile : la consultation du fichier de crédit, la décision, la signature et l'encaissement vivent dans des systèmes différents, et un crédit à mi-chemin ne peut pas rester sans responsable.

Comment Hábil MDW le résout : chaque demande porte son état et ses étapes ; votre équipe voit à quelle étape elle en est et de qui elle dépend, pour qu'aucun crédit ne reste sans responsable.

Capacités : Connecter vos systèmes · Les étapes de votre activité · Opérer 24/7 avec traçabilité.

Scénario : prix, stock et expéditions avec votre réseau de distribution · Commerce de détail et e-commerce

Avant : le prix dépend de la matière première, des variantes, du volume, du canal et du code promo. Il faut réserver le stock et coordonner les expéditions avec plusieurs transporteurs, entre plusieurs systèmes qui ne se parlent pas.

Ce qui change : le catalogue, le prix, le panier, le stock avec réservations et les expéditions passent par la même plateforme. Chaque expédition porte son bordereau et son état.

Pourquoi c'est difficile : le stock change dans le magasin, dans l'entrepôt et sur le réseau en même temps, et chaque transporteur répond à sa façon.

Comment Hábil MDW le résout : le stock est réservé au moment même de l'achat, une réservation conçue pour ne pas vendre deux fois la même pièce ; chaque transporteur se connecte par sa voie et sa réponse est traduite dans le même langage, et votre ERP reçoit chaque vente avec sa confirmation.

Capacités : Connecter vos systèmes · Les étapes de votre activité · Porte d'entrée gardée.

Scénario : la démarche qui n'arrive pas à échéance · Conformité environnementale et réglementaire

Avant : sites, autorisations, preuves et rappels vivent dans des dossiers et des feuilles de calcul. Une échéance manquée coûte une amende, ou une fermeture.

Ce qui change : chaque obligation a son dossier, sa preuve documentaire et son alerte avant l'échéance. On voit quel site a quelle démarche en attente et qui s'en occupe.

Pourquoi c'est difficile : les obligations viennent de plusieurs autorités, chacune avec ses délais, et les preuves sont entre les mains de personnes différentes.

Comment Hábil MDW le résout : chaque démarche est un processus avec ses états et ses délais ; la plateforme prévient la personne concernée, conserve la preuve avec sa date et laisse la trace prête pour l'auditeur.

Capacités : Les étapes de votre activité · Opérer 24/7 avec traçabilité.

Scénario : où en est chaque commande, sur une seule page · Traçabilité des commandes

Avant : une commande en ligne passe par le canal, l'encaissement, le stock, le point qui la prépare, le transporteur et la facturation. Chaque système connaît sa partie et aucun ne connaît l'histoire complète. Quand quelque chose se bloque, chaque service dit « de mon côté, tout s'est bien passé », et personne ne répond au client.

Ce qui change : avec le numéro d'une commande, on voit, sur une seule page, son parcours : à quelle étape elle en est, ce qui a été envoyé à chaque système, ce que chacun a répondu, ce qui manque et de qui dépend la suite.

Pourquoi c'est difficile : la trace est répartie dans les journaux de chaque système, avec des identifiants différents, et certains échecs ne signalent pas d'erreur : l'envoi est parti, mais la réponse n'est pas arrivée.

Comment Hábil MDW le résout : comme chaque opération passe par la plateforme, son parcours est déjà enregistré ; la plateforme le reconstitue, sépare ce qui a échoué de ce qui est encore en attente et dit qui a la balle dans son camp.

Capacités : Opérer 24/7 avec traçabilité · Connecter vos systèmes · Cohabiter avec l'existant.

Scénario : une commande, de nombreux canaux et une seule vérité · Vente et service client omnicanal

Avant : le client achète sur le web, pose une question par WhatsApp et retire en magasin. Chaque canal a sa version de la commande, et la notification qui arrive au client ne correspond parfois pas à ce qui s'est passé.

Ce qui change : chaque canal entre avec sa forme et la plateforme le convertit dans un même modèle de commande, avec l'état de chaque article. Les notifications au client — par WhatsApp, e-mail, SMS, notification ou dans votre application — partent du même état, et la facture est émise dans le même flux.

Pourquoi c'est difficile : chaque canal a son rythme et ses règles, et une notification qui part trop tôt annonce quelque chose qui n'est pas encore vrai.

Comment Hábil MDW le résout : les états de la commande, ses articles et ce qui se passe à chaque étape se définissent en configuration. Chaque notification au client est conçue pour partir lorsque ce qu'elle annonce s'est déjà produit.

Capacités : Connecter vos systèmes · Les étapes de votre activité · Opérer 24/7 avec traçabilité.

Où en est la commande 10482, sur une seule page

Exemple · données illustratives

La même commande : cherchée système par système, ou reconstituée par la plateforme. Changez l'état pour voir la différence.

Où en est la commande 10482, sur une seule page
Aujourd'hui : demander service par service
ÉtapeSystèmeÉtat
AchatBoutique en ligne« de mon côté, tout s'est bien passé »
EncaissementPasserelle de paiement« de mon côté, tout s'est bien passé »
RéservationStockaucune donnée
VenteERPaucune donnée
FactureFacturationaucune donnée

Chaque service dit que, de son côté, tout s'est bien passé, et personne ne sait où en est la commande.

Ce que fait la plateforme

Cinq capacités, présentées en trois parties : le problème, ce qui change et pourquoi c'est difficile.

1. Connecter votre système central, votre ERP et vos canaux, sans les remplacer

Le problème : le système central, l'ERP, la boutique en ligne, le centre de service client et les partenaires se parlent par des connexions faites sur mesure, une par une. Chacune vit à l'intérieur d'un système différent, et personne n'a la carte complète.

Ce qui change : nous nous connectons à votre système central et à votre ERP par les voies qu'ils possèdent déjà — services, base de données, fichiers — et à vos canaux par les leurs. Chaque système entre avec sa forme et la plateforme le convertit dans un même langage : une commande, une police ou un encaissement se décrivent de la même façon, d'où qu'ils viennent. Vos systèmes continuent de faire ce qu'ils font ; ce qui change, c'est qu'ils se comprennent désormais.

Pourquoi c'est difficile : chaque système nomme les choses à sa manière, et ce que l'un appelle « client », l'autre l'appelle « compte » ou « assuré ». Les équivalences s'écrivent avec votre équipe, une fois, et se testent à chaque opération.

2. Les étapes de votre activité, avec des preuves

Le problème : quand quelque chose se passe dans un système — un encaissement, une émission, une préparation de commande —, les autres l'apprennent tard, à moitié ou deux fois. Et les étapes suivantes vivent dans la tête de quelqu'un ou dans un code que personne ne veut toucher.

Ce qui change : chaque opération suit les étapes que votre activité définit : ce qui se passe après l'encaissement, qui est prévenu, ce qui est facturé, ce qu'on fait si un système ne répond pas. Les étapes et les états sont conçus pour se définir en configuration, pas dans le code ; changer une règle n'a donc pas à être un projet informatique. Quand un système doit savoir ce qui s'est passé dans un autre, il reçoit une notification. Si la notification arrive deux fois, elle est conçue pour que l'effet sur votre activité ne s'applique qu'une seule fois. Si une notification dépend d'une donnée qu'un autre système n'a pas encore renvoyée, la plateforme attend cette donnée et relance, au lieu d'envoyer un document incomplet.

Pourquoi c'est difficile : répéter une notification sans répéter l'encaissement exige de le concevoir dès le départ, opération par opération. L'ajouter après, sur des connexions déjà en usage, coûte beaucoup plus cher.

3. Une porte d'entrée gardée pour vos partenaires et vos systèmes

Le problème : vos partenaires — banques, magasins, agents, distributeurs — veulent coter, émettre ou encaisser depuis leur propre système. Leur ouvrir la porte sans contrôle est un risque ; ne pas la leur ouvrir, c'est vendre plus lentement.

Ce qui change : il y a une seule porte d'entrée, gardée. Chaque partenaire et chaque système entre avec sa propre identité et ne peut faire que ce que ses permissions lui permettent. Les limites d'usage — combien de requêtes, à quelles heures, sur quoi — se configurent par client et par partenaire. Chaque appel est enregistré, et si un identifiant est perdu, seul celui-là est révoqué, sans arrêter les autres partenaires.

Pourquoi c'est difficile : chaque partenaire a ses propres besoins, et la tentation est de mettre des règles métier dans la porte. Elles n'y ont pas leur place : la porte contrôle qui entre ; les règles vivent dans les processus, où elles peuvent être testées.

4. Conçue pour opérer 24/7, avec la trace de chaque opération

Le problème : une intégration qui échoue ne prévient pas : elle laisse un trou que quelqu'un comble à la main. Et quand le client demande où en est sa commande, la réponse est une enquête entre services.

Ce qui change : la plateforme est conçue pour opérer 24/7, avec la trace de chaque opération : ce qui a été envoyé à chaque système, ce qu'il a répondu, à quelle heure et, en cas d'échec, pourquoi. À partir d'un numéro de commande ou de police, la plateforme reconstitue son parcours et dit ce qui manque et de qui cela dépend : de la plateforme, de votre système central ou du canal. Un envoi qui a mal tourné est relancé par votre équipe d'exploitation comme un nouvel envoi, avec la trace de qui l'a fait et sans toucher à la base de données à la main.

Pourquoi c'est difficile : la trace doit servir deux publics — votre équipe d'exploitation, qui veut savoir quoi faire, et votre auditeur, qui veut des preuves — sans exposer les données personnelles qui circulent dans chaque opération.

5. Cohabiter avec vos anciens systèmes, et en sortir par étapes

Le problème : le système central a vingt ans, le bus d'intégration, plus personne ne veut le toucher, et le remplacement de l'ERP est repoussé d'année en année parce que personne ne sait ce qui va casser.

Ce qui change : nous nous connectons à votre système central par les voies qu'il possède déjà — services, base de données, fichiers —, même s'il s'agit d'une application de bureau, en veillant à ne toucher ni à sa logique ni à ses écrans ; si une extension est inévitable, nous vous le disons dans le diagnostic. Quand vous décidez de remplacer un système, nous concevons la cohabitation par étapes : vos canaux continuent d'alimenter le bon système, la migration se fait par tranches et l'ancienne connexion est coupée lorsque la nouvelle a démontré qu'elle concorde.

Pourquoi c'est difficile : tant que dure la cohabitation, les deux systèmes doivent raconter la même histoire. Cela exige de comparer, tranche par tranche, ce que dit l'ancien et ce que dit le nouveau.

Moderniser le système central

Où il s'exécute

Sur votre infrastructure — le cloud que vous payez déjà ou vos propres serveurs — ou sur la nôtre, l'exploitation étant assurée par Hábil. Chaque client dispose de sa propre installation : vos opérations ne se mélangent avec celles de personne d'autre.

S'il s'exécute sur la nôtre, votre installation a ses propres connexions, identifiants et traces. Dans les deux cas, nous installons, mettons à jour, sauvegardons et surveillons la plateforme, selon les horaires convenus, avec un service mensuel.

Ce que nous ne faisons jamais

Changer la logique ou les écrans de vos systèmes sans vous le dire avant. Nous nous connectons par les voies qu'ils possèdent déjà, et si une extension est inévitable, elle est convenue dans le diagnostic.

Mettre des règles métier dans la porte d'entrée, où personne ne peut ensuite les tester.

Ouvrir à un partenaire plus que ce que ses permissions lui permettent.

Mélanger vos opérations avec celles d'un autre client, ou utiliser vos données pour quelque chose que vous n'avez pas autorisé.

Couper une ancienne connexion avant que la nouvelle ne démontre qu'elle concorde.

Vous laisser dépendant : les règles et les étapes de votre activité sont écrites, et elles vous appartiennent.

Les détails du contrôle et de la sécurité suivent.

Contrôle, sécurité et vos données

Qui entre et ce qu'il peut faire

Chaque partenaire, chaque système et chaque personne entre avec sa propre identité, et ne peut faire que ce que ses permissions lui permettent. Les limites d'usage se configurent par client et par partenaire. Si un identifiant est perdu, seul celui-là est révoqué, sans affecter les autres.

Ce qui s'est passé avec chaque opération

Chaque opération est enregistrée avec ce qui a été envoyé, ce que chaque système a répondu, l'heure et, en cas d'échec, le motif. Quand quelqu'un demande ce qui est arrivé à une commande, une police ou un encaissement, la réponse est écrite, pas dans la mémoire d'une personne.

Vos données personnelles, en chemin

Elles circulent chiffrées entre les systèmes, sont masquées dans les journaux, et chaque système ne reçoit que ce dont il a besoin. Les règles se définissent avec votre équipe, selon vos politiques.

Des preuves pour votre auditeur

Les accès des partenaires et des systèmes, par identifiant et avec journal ; chaque opération, avec sa réponse et son heure. Des preuves consultables par votre auditeur, sans les chercher dans des e-mails.

Traçabilité et sauvegarde

La plateforme est sauvegardée avec un ordre de restauration écrit, et surveillée avec ses propres signaux : quelles opérations attendent une réponse, lesquelles ont échoué et depuis quand, quelle connexion a cessé de répondre.

Pour votre équipe technique

Comment c'est conçu. Une plateforme de petites pièces, chacune avec une responsabilité métier — commande, stock, encaissement, facturation, expéditions, notifications, identité, entre autres —, qui communiquent par événements et par API.

Par capacité.

Connexion.

Des adaptateurs par système vers votre système central et votre ERP, par les interfaces qu'ils exposent déjà : services SOAP ou REST, procédures stockées ou tables d'échange, fichiers. Pour les ERP, nous privilégions les interfaces que l'éditeur prend en charge — dans SAP, par exemple, JCo, OData, IDoc ou REST ; aussi Oracle, Microsoft Dynamics 365, Odoo ou CONTPAQi —, pour ne pas vous laisser de développements qui gênent ses mises à jour. Des bases de données comme Oracle, DB2 (y compris sur IBM i), SQL Server, PostgreSQL, MySQL, MariaDB ou MongoDB. Chaque adaptateur traduit vers le modèle commun.

Orchestration et événements.

Le flux de chaque opération est une machine à états décrite en configuration ; ajouter un canal ou une issue n'exige pas de recompiler. Les événements suivent le standard CloudEvents et circulent par un bus utilisant le protocole de Kafka ou par la file que votre entreprise opère déjà (IBM MQ, RabbitMQ ou une autre). Chaque consommateur est idempotent : il est conçu pour qu'un événement répété ne répète pas l'effet.

API gardées.

Une passerelle unique avec identité (OAuth 2.0 / OpenID Connect), permissions par consommateur, limites d'usage configurables par client et enregistrement de chaque appel. Ce peut être celle que vous avez déjà — Apigee, Azure API Management, Amazon API Gateway, Kong, WSO2, APISIX ou une autre. API REST ou GraphQL, avec un contrat publié et versionné.

Exploitation et trace.

Journal structuré par opération, avec un identifiant qui la suit d'un système à l'autre, métriques et traces selon des standards ouverts (OpenTelemetry), et relances avec attente, conçues pour ne pas répéter l'effet. La reconstitution du parcours d'une commande s'appuie sur cette trace.

Cohabitation avec l'existant.

Connexion avec IBM i (AS/400), avec des programmes RPG exposés comme services sans les réécrire ; avec des bus hérités comme WebSphere ESB, IBM Integration Bus, MuleSoft ou WSO2, qui restent en place pendant la migration tranche par tranche.

Fiscal.

Facturation CFDI avec complément de paiement et annulations, orchestrée vers votre fournisseur de timbrage.

Installation. Une installation par client, en conteneurs, sur votre infrastructure ou la nôtre. Chaque intégration a sa propre identité et son chiffrement, et seul l'indispensable est exposé vers l'extérieur. Sans licences d'entreprise payantes : des composants ouverts ou d'usage libre, conçus pour être remplacés sans refaire les intégrations.

Hábil MDW avec Hábil AI et Hábil Lake

Les trois grandes solutions de Hábil se partagent le travail : Hábil MDW connecte vos systèmes, Hábil Lake organise vos données et Hábil AI répond et accompagne avec elles. Ce sont trois plateformes indépendantes : elles se contractent séparément et aucune n'exige les autres. Quand vous en avez plusieurs, elles s'alimentent ainsi :

Ce qui se passe arrive au Lake.

Chaque opération qui traverse Hábil MDW — une commande, un encaissement, une police — peut arriver dans Hábil Lake au fil de l'eau, avec son historique. Le Lake l'organise et la rapproche du système d'origine.

Votre IA agit par la même porte.

Quand un agent de Hábil AI consulte une commande ou prépare un remboursement, il le fait par la porte d'entrée gardée de Hábil MDW, avec sa propre identité, ses permissions et la trace de chaque appel. Ce qui engage de l'argent ou des données est exécuté avec l'approbation d'une personne.

Nova sait où en est la commande.

Quand un client demande par WhatsApp où en est sa commande, Nova lui répond avec l'état que suit Hábil MDW, pas avec une supposition.

L'IA lit la trace.

Chaque matin, un agent passe en revue les opérations bloquées, trouve le motif de chacune dans la trace de la plateforme et les laisse à votre équipe.

Les prévisions reviennent à l'exploitation.

Ce que la prévision de Hábil AI estime — par exemple, le réapprovisionnement — arrive dans vos systèmes par Hábil MDW, sous forme de proposition qu'une personne approuve.

Découvrez Hábil Lake : une seule version de vos chiffres, rapprochée de votre système.

Découvrez Hábil AI : l'IA qui travaille avec vos systèmes, avec une personne qui approuve tout ce qui engage de l'argent ou des données.

Comment nous commençons

Lors d'un premier échange, sans frais, nous choisissons le flux de votre activité qui se bloque le plus aujourd'hui.

1

Vous nous écrivez sur WhatsApp en indiquant votre secteur, votre fonction et vos systèmes principaux.

2

Nous planifions 45 minutes avec un architecte de Hábil.

3

Nous vous demandons quels systèmes vous utilisez, comment ils sont connectés aujourd'hui et où la trace se perd. Nous ne demandons ni accès ni données de vos clients.

4

Vous repartez avec une cartographie de vos connexions : quel système parle avec lequel, par quelle voie, lesquels échouent sans prévenir, quels risques nous voyons et s'il est pertinent d'avancer.

5

Si c'est pertinent : nous commençons par le niveau Pour démarrer, avec périmètre, livrables et coût convenus avant le début, et un objectif clair pour clore cette étape : que le premier flux passe par la plateforme, avec sa trace en vue.

Le parcours est : diagnostic → proposition avec périmètre, coût et risque → premier flux connecté → exploitation.

Ce dont nous avons besoin de votre équipe : une personne qui connaît le flux et décide de ses règles, les accès aux systèmes à connecter au démarrage et la validation du flux avant de couper l'ancienne connexion.

Nous travaillons avec peu de clients à la fois : l'architecte qui examine votre diagnostic suit votre projet jusqu'au bout.

Nous vous disons non lorsque vos systèmes se parlent déjà bien et que personne ne rapproche à la main, lorsque le flux vit dans un seul système, ou lorsque le coût de la plateforme dépasse le travail manuel qu'elle vous épargne.

Questions fréquentes

Ce qu'on nous demande avant de commencer

  1. Non. Hábil MDW s'y connecte par les voies qu'ils possèdent déjà — services, base de données, fichiers —, en veillant à ne toucher ni à leur logique ni à leurs écrans. Vos systèmes continuent de faire ce qu'ils font.

  2. C'est l'une des raisons d'avoir la plateforme. Nous nous connectons par les voies dont il dispose, même s'il s'agit d'une application de bureau vieille de vingt ans, et si un jour vous le remplacez, la cohabitation se conçoit par étapes.

  3. L'opération attend et relance, et votre équipe voit à quelle étape elle en est et de qui elle dépend. Les relances sont conçues pour ne pas répéter l'effet, par exemple pour qu'un encaissement relancé ne génère pas un deuxième débit.

  4. Oui. Ils entrent par une porte d'entrée gardée, chacun avec son identité, ses permissions et ses limites d'usage, qui se configurent par client et par partenaire. Chaque appel est enregistré.

  5. Sur votre infrastructure ou sur la nôtre, dans une installation rien que pour vous. Elles circulent chiffrées, sont masquées dans les journaux, et chaque système ne reçoit que ce dont il a besoin.

  6. Pas nécessairement. Les étapes, les états et les règles de chaque flux sont pensés pour se définir en configuration. Votre équipe les modifie avec nous, et ils restent écrits.

  7. Non. Ils se contractent séparément. Si plus tard vous voulez que vos opérations arrivent au Lake ou que votre IA agisse dans vos systèmes, on les connecte.

  8. Les règles, les étapes et la cartographie de vos connexions sont écrites et vous appartiennent, tout comme la trace de vos opérations. La plateforme utilise des standards ouverts, et elle est conçue pour qu'on puisse changer une pièce sans refaire les intégrations.

  9. Le périmètre et le coût sont convenus avant le début. Ce qui les fait le plus varier : combien de systèmes et de partenaires sont connectés, combien de flux, combien d'opérations et à quelle fréquence, s'il y a des données personnelles à protéger, le niveau que vous choisissez et s'il s'exécute sur votre infrastructure ou sur la nôtre.

Votre question n'y est pas ?

Parlons de votre cas. En 45 minutes, nous vous disons si cela convient, ce qui dépend de vos systèmes et quel risque vous devez résoudre avant d'aller plus loin. Premier échange, sans frais.

Parlons de votre cas

Vous préférez l'e-mail ? Écrivez-nous à hola@habil.mx