Questions fréquentes

Nous estimons à partir du périmètre, et non d’une grille tarifaire. Après un premier échange, nous découpons le travail en lots, dimensionnons chacun d’eux et consignons par écrit les hypothèses de l’estimation. Les principaux facteurs sont le nombre de systèmes et d’intégrations, l’état de vos données, les exigences de sécurité et réglementaires, les tests nécessaires et la séniorité de l’équipe. Vous recevez une estimation écrite avec des options, pour choisir ce qui doit être réalisé en premier. Vous connaissez le prix et le calendrier avant que nous commencions.

Les principaux facteurs sont l’état de vos données, le nombre de systèmes à intégrer, le niveau de précision requis et la part de validation humaine que le processus exige. Les coûts d’exploitation comptent aussi : utilisation des modèles, hébergement et supervision. Nous chiffrons après un court cadrage, distinguons le coût de développement du coût d’exploitation et montrons comment ce dernier évolue avec les volumes, pour éviter toute surprise.

Le coût de développement dépend du nombre et de l’état de vos sources, des intégrations et des droits d’accès concernés, ainsi que du niveau d’exactitude exigé. Le coût d’exploitation dépend de l’usage, du modèle retenu, du volume de texte envoyé avec chaque requête et de la mise en cache. Nous chiffrons les deux et montrons comment un modèle plus petit ou une meilleure récupération peut réduire le coût d’exploitation.

Les principaux facteurs sont l’état et l’accessibilité de vos données, l’existence d’étiquettes ou la nécessité de les créer, le nombre de systèmes auxquels le modèle doit se connecter, et le niveau d’explication et de documentation attendu par vos régulateurs. Les coûts d’exploitation dépendent du volume de prédictions et du besoin de résultats en temps réel ou par lots. Nous chiffrons une fois la revue des données terminée.

Le coût de construction dépend du nombre et de la complexité des sources, de leur propreté, et du nombre de domaines et de rapports concernés. Le coût d’exploitation dépend des volumes de données, de la fréquence d’actualisation et des modes d’interrogation. Nous chiffrons les deux, concevons la plateforme pour maîtriser les dépenses de calcul et mettons en place un suivi des coûts pour que l’usage n’augmente pas à votre insu.

Le nombre de types et de mises en page de documents, la qualité des numérisations, le nombre de règles de validation et de systèmes concernés, et le volume traité. Le coût d’exploitation dépend des volumes et des services d’extraction utilisés. Nous chiffrons après avoir testé un échantillon de vos documents, et indiquons la part de documents qui devrait encore nécessiter une intervention humaine.

Le périmètre est le principal facteur : le nombre de rôles utilisateurs, de processus et d’écrans, le nombre de systèmes auxquels le logiciel doit se connecter, et le niveau d’exigence en matière de sécurité, d’audit et de disponibilité. L’état de vos données et le nombre de personnes qui doivent valider les décisions comptent aussi. Nous chiffrons après le cadrage, à partir d’un backlog priorisé, afin que vous puissiez choisir ce qui entre dans la première version et ce qui peut attendre.

Le nombre de rôles utilisateurs et de processus, les intégrations derrière l’application, les langues et les mises en page qu’elle doit prendre en charge, ainsi que ses exigences de sécurité et d’audit. Le niveau de conception compte aussi : un outil destiné à une petite équipe interne en demande moins qu’un portail public sur lequel vos clients s’appuient. Nous chiffrons à partir du backlog après le cadrage, afin que vous puissiez décider de ce qui entre dans la première version.

Le nombre de parcours et d’écrans, le choix entre une application native par plateforme ou une seule application multiplateforme, le travail côté back-end et le niveau de sécurité requis. L’utilisation hors ligne, les paiements, les fonctionnalités de l’appareil et l’éventail d’appareils à prendre en charge ajoutent de l’effort. Les publications sur les boutiques et l’adaptation aux nouvelles versions des systèmes d’exploitation sont des coûts récurrents à prévoir.

Le nombre d’applications et d’environnements, l’écart qui les sépare aujourd’hui d’un déploiement automatisé, les contrôles de conformité à respecter, et le fait que les charges de travail changent de fournisseur ou quittent votre propre centre de données. L’exploitation dans la durée est une décision distincte : nous pouvons exploiter la plateforme avec vous, ou la transmettre lorsque votre équipe est prête.

Souvent, mais nous ne promettrons aucun chiffre avant d’avoir examiné la situation. Les économies courantes proviennent de ressources inutilisées, d’instances surdimensionnées, d’un stockage qui n’expire jamais et d’environnements qui tournent quand personne ne travaille. Nous étiquetons d’abord les dépenses par équipe et par service, afin que les économies soient mesurées et non estimées, et nous classons nos constats par effort et par risque.

Le nombre d’applications et de parcours dans le périmètre, la testabilité du code actuel, l’état de vos données et environnements de test, et le nombre d’intégrations à simuler. Une application ancienne sans points d’ancrage stables pour les tests demande plus d’effort qu’une application récente conçue en pensant aux tests. Nous commençons par les parcours les plus risqués, pour que la valeur arrive tôt.

Le nombre de groupes d’utilisateurs et de parcours, l’ampleur de la recherche nécessaire, l’existence ou non d’un système de design, et le nombre de plateformes et de langues que le design doit couvrir. La refonte d’un produit établi comportant de nombreux écrans demande plus que la conception d’un nouvel outil ciblé. Nous définissons le périmètre du design par étapes, afin que vous puissiez examiner les constats et les parcours avant de vous engager sur l’interface complète.

La taille et la complexité de l’ancien système, la qualité de ses données, le nombre de systèmes qui en dépendent, et la part de ce qui doit changer plutôt qu’être conservé. Les langages et bases de données anciens que peu d’ingénieurs maîtrisent ajoutent de l’effort. Le travail étant incrémental, vous pouvez le financer par étapes et constater le résultat de chacune avant de valider la suivante.

Le nombre d’interfaces, la complexité de la correspondance des données et des règles métier, les volumes et les délais requis par chaque flux, et la présence éventuelle de licences middleware. Le nettoyage des données et les tests avec les partenaires représentent un effort supplémentaire. Nous chiffrons chaque interface après l’évaluation, afin que vous puissiez voir le coût de chaque flux et en décider l’ordre.

Le nombre de banques et de canaux, les types de paiement et les pays du périmètre, ce que votre ERP prend déjà en charge, et la complexité de vos règles de rapprochement. Les exigences de signature et de chiffrement ainsi que le processus de test de chaque banque demandent un effort supplémentaire. Nous chiffrons par banque et par flux après le cadrage, afin que vous puissiez échelonner les travaux et leur coût.

Le nombre de prestataires, de types de terminaux et de canaux de vente, l’usage d’ISO 8583 ou d’une API par l’acquéreur, les étapes de certification exigées par chaque prestataire et le nombre de magasins à déployer. Les règles de règlement et de rapprochement demandent un effort supplémentaire lorsque les commissions et les versements sont complexes. Nous chiffrons par prestataire et par flux après l’étape de cartographie.

Le nombre de partenaires et de flux, la qualité de leurs API, la correspondance des données et les règles métier, les besoins de volume et de délai, et les éventuelles licences de plateforme d’intégration. La gestion des identités et la certification auprès d’un partenaire demandent un effort supplémentaire. Nous chiffrons chaque liaison après l’inventaire, afin que vous puissiez choisir l’ordre et voir le coût de chacune.

Une équipe dédiée est généralement facturée selon un coût mensuel pour les rôles convenus, ce qui vous permet de planifier votre budget. Le coût dépend du nombre de personnes, de leur niveau d’expérience et de leurs compétences, ainsi que de toute couverture en dehors des horaires habituels. Si vous préférez payer le temps réellement passé, nous pouvons travailler en régie. Vous connaissez le prix et le calendrier avant que nous commencions.

Généralement en régie : un taux par ingénieur pour le temps passé, ou un taux mensuel pour une mission à temps plein. Le taux dépend des compétences et du niveau d’expérience requis, ainsi que de tout travail en dehors des horaires habituels. Vous connaissez le prix et le calendrier avant que nous commencions.

Elle peut le modifier. Le coût dépend des rôles, des niveaux d’expérience et des compétences nécessaires, ainsi que de ceux qui peuvent les fournir. Vous connaissez le prix et le calendrier avant que nous commencions. Toute modification de la répartition est convenue au préalable avec vous.

Un périmètre bien défini peut faire l’objet d’un prix au forfait pour ce périmètre, les changements étant traités par la gestion des changements. Lorsque le périmètre est moins certain, nous chiffrons séparément le cadrage puis le développement, ou nous travaillons en régie dans la limite d’un budget dont nous rendons compte. Vous connaissez le prix et le calendrier avant que nous commencions.

Généralement au forfait, pour un périmètre fixe, convenu après un court échange de cadrage, ou sous forme d’un nombre de jours de consultant pour un accompagnement ouvert. Le prix dépend de l’étendue du système d’information à examiner, du nombre d’options à comparer et de la profondeur d’analyse que la décision exige. Vous connaissez le prix et le calendrier avant que nous commencions.

Elle est généralement réalisée au forfait, pour un périmètre défini et convenu après un court échange de cadrage. Le prix dépend du nombre de directions métier concernées, du nombre de cas d’usage évalués en profondeur et de l’ampleur de l’examen concret de vos données et de vos systèmes. Vous connaissez le prix et le calendrier avant que nous commencions.

Le nombre de systèmes et de partenaires concernés, les contrôles réglementaires applicables, le volume et la vitesse que le système doit absorber, et l’ampleur des tests exigés par les partenaires avant la mise en production. L’intégration auprès des partenaires, comme la certification par une banque ou un processeur, dicte souvent le rythme davantage que le code. Nous établissons une estimation après le cadrage et découpons le travail en étapes que vous pouvez financer et approuver une à une.

Le nombre de systèmes, de magasins et de canaux, la façon dont le POS et l’ERP exposent leurs données, et le nombre d’exceptions qui nécessitent des règles, comme les retours entre canaux ou les paiements fractionnés. Un déploiement magasin par magasin ajoute aussi des tests. Nous chiffrons après avoir étudié les systèmes et un échantillon de transactions réelles.

Le nombre de partenaires et de formats, le nombre de types de messages nécessaires pour chacun, la qualité des environnements de test des partenaires, et la part du processus qui repose encore sur le papier ou l’e-mail. Nous chiffrons par partenaire et par flux après une étude, pour que vous puissiez commencer par les partenaires les plus importants et ajouter les autres par étapes.

Le nombre de systèmes à intégrer, les validations à obtenir des éditeurs, le travail sur la confidentialité et la sécurité clinique, ainsi que les tests d’accessibilité et d’ergonomie avec les patients et le personnel. Nous chiffrons après le cadrage et découpons le travail en étapes, en commençant par celle qui supprime le plus de tâches manuelles.

Le nombre de services et d’intégrations, les fournisseurs d’identité et de paiement concernés, les évaluations d’accessibilité et de sécurité, et la recherche utilisateur dont le service a besoin. Nous chiffrons par étape, afin qu’un cadrage ou un pilote puisse être validé seul avant le développement complet.

Le nombre de systèmes et de partenaires, le nombre de types de messages nécessaires pour chacun, la qualité des données, les possibilités d’extension de votre version d’ERP et le volume de tests exigé par vos partenaires. Nous chiffrons par flux après le cadrage, pour que vous puissiez commencer par les flux qui économisent le plus d’efforts.

L’engagement dépend du modèle et est convenu avec vous. Un projet se poursuit jusqu’à l’achèvement du périmètre convenu. Les équipes et les missions de renfort sont assorties de préavis, afin que chacun puisse arriver et partir dans de bonnes conditions et que le travail soit transmis. Nous formalisons ces conditions par écrit avant tout démarrage.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Cela couvre le code spécifique, la documentation et les autres livrables réalisés pour vous. Les éléments préexistants que nous apportons, tels que des outils internes ou des bibliothèques, restent notre propriété, et vous recevez une licence pour les utiliser dans vos systèmes. Les composants open source conservent leurs propres licences, et nous vous en fournissons la liste.

Oui. Nous signons un accord de confidentialité réciproque avant que vous ne partagiez la moindre information confidentielle, sur votre modèle ou le nôtre. Toute personne qui travaille sur votre projet est tenue à des obligations de confidentialité, qu’elle soit salariée de XSIS ou membre d’une équipe externalisée.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Cela inclut le code, les prompts, les jeux d’évaluation et les modèles ajustés produits pour vous, et vos données restent les vôtres. Les outils XSIS préexistants restent notre propriété et vous sont concédés sous licence. Les modèles et services tiers restent soumis à leurs propres licences, que nous vous listons pour que vous sachiez ce que chaque composant autorise.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Cela inclut le code, les prompts, les jeux d’évaluation, les index de recherche et les poids de tout modèle ajusté produits pour vous. Les outils XSIS préexistants restent notre propriété et vous sont concédés sous licence. Les modèles commerciaux restent la propriété de leur éditeur et sont utilisés selon ses conditions, que nous vous listons. Vos documents et vos données restent les vôtres du début à la fin.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Cela inclut les modèles entraînés, le code des variables, les pipelines et la documentation produits pour vous, et vos données restent les vôtres. Les outils XSIS préexistants restent notre propriété et vous sont concédés sous licence. Les bibliothèques open source que nous utilisons restent soumises à leurs propres licences, que nous consignons pour vous.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Le code spécifique, les maquettes et les documents produits par l’équipe sont conservés dans vos propres dépôts et outils. Les outils XSIS préexistants restent notre propriété et vous sont concédés sous licence. Chaque membre de l’équipe, y compris les ingénieurs issus d’équipes externalisées, est soumis aux mêmes obligations de confidentialité.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Les travaux qu’un ingénieur produit pour vous sont conservés dans vos propres dépôts. Les outils XSIS préexistants restent notre propriété et vous sont concédés sous licence. Chaque ingénieur signe nos engagements de confidentialité et respecte vos politiques de sécurité lorsqu’il travaille dans vos systèmes.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Cela couvre les logiciels spécifiques, les maquettes et les documents livrés pour vous. Les outils ou bibliothèques existants qui nous appartiennent et sont utilisés dans le projet restent notre propriété, sont désignés dans le contrat et vous sont concédés sous licence.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Les connecteurs vous sont livrés avec leur code source, leurs tests et leur documentation, afin que votre équipe ou un autre prestataire puisse les maintenir. Les outils XSIS préexistants restent notre propriété et vous sont concédés sous licence. Les API des partenaires et les licences des plateformes d’intégration restent soumises aux conditions propres de leurs éditeurs.

XSIS emploie ses propres ingénieurs, qui pilotent les projets, fixent l’orientation technique et répondent de la qualité. Lorsqu’un projet exige davantage de capacité ou une compétence spécialisée, nous faisons appel à des ingénieurs de partenaires d’externalisation sélectionnés et évalués. Ils appliquent les mêmes standards, les mêmes contrats et les mêmes règles de sécurité, et vous savez toujours qui fait partie de votre équipe et qui l’emploie.

Vous menez un entretien avec chaque ingénieur avant son arrivée : aucun placement à l’aveugle. Si une personne ne convient pas, nous la remplaçons sans frais. Signalez-le à votre directeur de projet, et nous organisons une passation afin que les connaissances restent dans l’équipe. Il en va de même si une personne doit quitter le projet pour des raisons personnelles.

Oui. De nombreux clients souhaitent que leurs ingénieurs travaillent dans le même dépôt dès le départ, afin que les connaissances restent en interne. Nous définissons ensemble les règles de travail : revue de code, stratégie de branches, définition de « terminé » et validation des mises en production. Vos ingénieurs peuvent participer aux itérations, travailler en binôme avec les nôtres ou reprendre certaines parties du système lorsqu’ils sont prêts.

C’est l’objectif. Tout est décrit en code et documenté, et vos ingénieurs relisent et valident les modifications avec nous dès le départ. Nous travaillons en binôme avec eux sur les incidents et les mises en production, rédigeons des manuels d’exploitation pour les tâches courantes et nous retirons progressivement à mesure qu’ils prennent le relais. Si vous préférez que nous continuions à exploiter la plateforme, cela peut se poursuivre dans le cadre d’un contrat de support.

Oui. Nous rejoignons souvent une équipe QA interne pour apporter des compétences en automatisation, prendre en charge les tests de performance ou de sécurité, ou absorber une période chargée. Nous convenons de la répartition du travail, utilisons les mêmes outils et le même backlog, et formons vos testeurs pour qu’ils étendent les suites que nous construisons.

Dans la même équipe et au même rythme. Les designers participent à la planification, transmettent les maquettes et les composants avec leurs états et leur comportement documentés, et revoient ce qui est développé avant la livraison. Les ingénieurs participent tôt à la recherche et aux revues de design, afin que les idées difficiles à réaliser soient repérées avant d’être peaufinées.

Oui, et c’est une situation courante. Nous reconstituons la connaissance à partir du code, des données, des journaux et des personnes qui utilisent le système, et nous consignons ce qu’il fait réellement dans des tests de caractérisation. Ces tests deviennent la spécification à laquelle les nouvelles parties doivent répondre, de sorte que les comportements non documentés sont conservés, sauf si vous décidez de les modifier.

Nous partons des compétences que le travail exige, et non des disponibilités. Les candidats passent des entretiens techniques et des exercices pratiques conduits par nos ingénieurs seniors, et nous vérifions leur expérience au regard de votre type d’activité. Nous vous adressons ensuite leurs profils, et vous menez vous-même les entretiens. Personne ne rejoint votre équipe sans votre accord.

Vous décidez de ce sur quoi l’équipe travaille : votre product owner fixe les priorités et valide le travail. Nous pilotons l’équipe au quotidien par l’intermédiaire d’un responsable d’équipe qui planifie le travail, lève les blocages, veille à la qualité et vous rend compte. Le management hiérarchique, le suivi de la performance et le remplacement des personnes restent du ressort de XSIS.

Vous menez un entretien avec chaque ingénieur avant son arrivée : aucun placement à l’aveugle. Si une personne ne convient pas, nous la remplaçons sans frais. Signalez-le à votre responsable d’équipe ou à votre interlocuteur commercial dès que vous le constatez. Nous examinons aussi le rôle et le cadrage, qui sont parfois la véritable cause, et nous organisons une période de recouvrement afin que les connaissances soient transmises et non perdues.

Oui. L’équipe suit votre feuille de route. Vous pouvez ajouter des rôles au lancement d’un nouveau chantier et les libérer à son terme. Nous convenons avec vous de chaque changement à l’avance, avec un préavis suffisant pour intégrer correctement de nouvelles personnes ou transmettre proprement leur travail. Les conditions de préavis sont fixées dans le contrat.

Avec le renfort d’équipe, nos ingénieurs rejoignent votre équipe et vos managers dirigent leur travail au quotidien. Avec une équipe dédiée, nous fournissons une équipe complète avec son propre responsable, et nous la pilotons au quotidien tandis que vous fixez les priorités. Le renfort d’équipe convient lorsque vous disposez déjà de l’encadrement et des processus. L’équipe dédiée convient lorsque vous souhaitez nous en confier une plus grande part.

Nos ingénieurs seniors conduisent des entretiens techniques et des exercices pratiques pour chaque candidat, au regard de votre fiche de poste. Nous vérifions ses réalisations passées et le type de systèmes qu’il a construits. Les ingénieurs issus d’équipes externalisées passent la même évaluation que les nôtres. Vous menez ensuite vous-même les entretiens, et seules les personnes que vous choisissez vous rejoignent.

Vos managers dirigent le travail : ce qui doit être construit, dans quel ordre et selon quelles modalités de revue. XSIS reste l’employeur ou la partie contractante. Nous prenons en charge la rémunération, les congés, l’équipement, l’accompagnement de la performance et le remplacement, et notre interlocuteur commercial reste en contact avec vous et avec l’ingénieur.

Vous menez un entretien avec chaque ingénieur avant son arrivée : aucun placement à l’aveugle. Si une personne ne convient pas, nous la remplaçons sans frais. Prévenez-nous le plus tôt possible, et nous organisons la passation afin que les travaux en cours ne soient pas perdus.

Oui. Vous pouvez ajouter des personnes au démarrage d’un nouveau chantier et les libérer à son terme. Le contrat fixe le préavis applicable de part et d’autre, afin que de nouveaux ingénieurs puissent être trouvés et évalués correctement et que ceux qui partent puissent transmettre leur travail.

Cela signifie que nos propres ingénieurs dirigent chaque mission et en portent la responsabilité, et que nous ajoutons des ingénieurs issus d’équipes externalisées sélectionnées et évaluées lorsque le travail exige davantage de personnes ou une compétence dont nous ne disposons pas en interne. Les ingénieurs externalisés travaillent sous notre contrat et selon nos standards, au sein d’une équipe dirigée par nos collaborateurs.

Oui. La cartographie de l’équipe recense chaque personne, son rôle et son employeur. Vous menez un entretien avec chaque ingénieur avant son arrivée : aucun placement à l’aveugle. Nous n’ajoutons ni ne remplaçons personne sans vous en informer au préalable.

XSIS. Votre contrat est conclu avec nous, et notre directeur de projet répond du travail de toute l’équipe, quel que soit l’employeur de chaque ingénieur. C’est pourquoi nos ingénieurs revoient les modifications des ingénieurs externalisés avant leur fusion, et pourquoi un seul ensemble de standards s’applique à tous.

Oui. Indiquez-le-nous avant que nous proposions l’équipe. Certains clients exigent que certains travaux, comme l’accès aux données de production, soient réalisés uniquement par des ingénieurs XSIS. Nous organisons les rôles en conséquence et vous indiquons clairement si cela modifie ce que nous pouvons livrer, ou les délais.

Cela dépend du modèle, et nous le précisons par écrit. En mode projet, XSIS est responsable de la réalisation du périmètre convenu. Avec une équipe dédiée, XSIS est responsable de la bonne gestion de l’équipe et vous êtes responsable de ses priorités. En renfort d’équipe, vos managers dirigent le travail et XSIS répond des personnes qu’elle fournit.

Oui. Une équipe dédiée peut faire évoluer votre produit pendant qu’un projet distinct réalise une intégration bancaire, ou nous pouvons placer un spécialiste dans votre propre équipe en parallèle d’une équipe que nous dirigeons. Chaque volet a ses propres conditions, et un interlocuteur XSIS unique en assure la coordination.

Avant le développement, nous convenons avec vos équipes d’un jeu d’évaluation : des exemples réels accompagnés des réponses attendues par vos experts. Chaque version du système est notée sur ce jeu, et des relecteurs vérifient un échantillon des cas les plus difficiles. Vous fixez le seuil de mise en production. En production, nous continuons à mesurer et orientons les cas incertains vers une personne plutôt que de laisser le système deviner.

Nous travaillons avec des modèles commerciaux tels que les modèles OpenAI GPT, Anthropic Claude et Google Gemini, avec des modèles ouverts tels que Meta Llama et Mistral, et avec l’apprentissage automatique classique lorsqu’il convient mieux. Nous choisissons tâche par tâche selon la qualité, le coût, la latence et le lieu où le modèle peut s’exécuter. Nous concevons les systèmes pour que le modèle puisse être remplacé plus tard. La mention d’un fournisseur ne signifie pas un partenariat.

Nous réduisons le risque par couches successives. Le modèle répond à partir de passages de vos contenus et doit les citer. Des garde-fous vérifient que chaque affirmation est étayée par ces passages. Lorsque les sources ne contiennent pas la réponse, la fonctionnalité l’indique au lieu de deviner. Le jeu d’évaluation mesure la fréquence des réponses non étayées, et nous ne mettons en production qu’une fois ce taux conforme au seuil que vous avez fixé.

Pour répondre à partir de vos documents, la récupération est généralement le meilleur point de départ : elle garde les réponses à jour, montre les sources et respecte les droits d’accès. L’ajustement fin (fine-tuning) est utile lorsque vous avez besoin d’un format ou d’un style constant, d’un vocabulaire spécialisé ou d’un modèle plus petit et peu coûteux à exécuter. De nombreux systèmes combinent les deux. Nous testons les options sur votre jeu d’évaluation et recommandons la plus simple qui atteint le niveau exigé.

Nous choisissons tâche par tâche, selon la qualité des réponses sur votre jeu d’évaluation, le coût par requête, la rapidité, les langues prises en charge et le lieu où le modèle est autorisé à s’exécuter. Les options comprennent les modèles OpenAI GPT, Anthropic Claude, Google Gemini, Meta Llama et Mistral, via des services tels qu’Azure OpenAI, Amazon Bedrock ou Vertex AI. Le modèle se trouve derrière une interface unique et peut donc être remplacé plus tard.

Cela dépend du problème, pas d’un volume fixe. L’essentiel est de disposer d’un historique suffisant pour couvrir les schémas que le modèle doit apprendre, y compris les saisons et les événements rares, et d’étiquettes fiables pour le résultat à prédire. Nous le vérifions lors de la revue des données et vous disons clairement si les données ne permettent pas encore d’atteindre la cible, et ce qu’il faut collecter pour y parvenir.

Le choix dépend de votre cloud, de vos volumes, de vos compétences et de votre budget plus que d’un produit en particulier. Snowflake, Databricks, BigQuery et Amazon Redshift conviennent à la plupart des entreprises, et PostgreSQL suffit dans bien des cas. Nous comparons les options à vos exigences et à vos contrats existants, et concevons les transformations, écrites en SQL avec dbt, pour qu’elles restent portables.

Oui. Nous utilisons les méthodes d’extraction prises en charge par l’ERP, comme ses API, ses services d’export ou la capture des changements depuis une réplique, plutôt que des requêtes lourdes sur la base de production. Les chargements sont planifiés en dehors des heures de pointe si nécessaire. Pour SAP, Oracle, Microsoft Dynamics 365, NetSuite et Odoo, nous suivons l’approche recommandée par chaque éditeur.

Uniquement pour les décisions qui ne peuvent pas attendre, comme le filtrage de la fraude, la disponibilité des stocks ou le statut des paiements. Pour la plupart des rapports, des chargements toutes les heures ou chaque nuit suffisent et coûtent bien moins cher à exploiter. Nous utilisons le streaming avec Apache Kafka ou la capture des changements lorsque le temps réel est nécessaire, et le traitement par lots dans les autres cas, et nous décidons avec vous cas d’usage par cas d’usage.

La plupart des documents de gestion structurés et semi-structurés : factures fournisseurs, avoirs, reçus, relevés et avis bancaires, bons de commande, bons de livraison, documents douaniers et d’expédition, déclarations de sinistre, formulaires de demande et pièces d’identité. L’écriture manuscrite, les numérisations de mauvaise qualité et les mises en page inhabituelles réduisent l’exactitude : c’est pourquoi nous mesurons sur vos propres échantillons avant de convenir du périmètre.

Non. La RPA reproduit des clics à l’écran et cesse de fonctionner dès que l’écran change. Nous lisons le document avec l’IA documentaire, le vérifions avec des règles métier et le comptabilisons via les interfaces prises en charge par l’ERP. Lorsqu’un système n’offre aucune interface, l’automatisation d’écran peut être un dernier recours, et nous vous le signalons lorsque nous y recourons.

Nous comptabilisons dans SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365, Odoo et Sage, ainsi que dans des systèmes sur mesure et des outils de workflow, via leurs API, leurs services d’import ou des plateformes d’intégration. La comptabilisation suit les règles d’approbation que vos équipes appliquent aujourd’hui. La mention d’un produit ne signifie pas un partenariat avec son éditeur.

Nous partons de ce que votre équipe sait exploiter et peut recruter, de ce qu’utilisent vos autres systèmes et de ce que le logiciel doit faire. Pour la plupart des logiciels métier, cela signifie un langage courant comme TypeScript, Java, C# ou Python, une base de données relationnelle comme PostgreSQL ou SQL Server, et le cloud que vous utilisez déjà. Nous évitons les outils de niche, sauf s’ils résolvent un problème réel, et nous consignons chaque choix et ses raisons.

Nous utilisons React avec Next.js pour la plupart des nouvelles applications, car il prend en charge le rendu côté serveur, dispose d’un outillage solide et est largement connu des ingénieurs. Nous travaillons aussi avec Angular et Vue, et nous poursuivons dans le framework que vous utilisez déjà lorsque c’est le choix le plus judicieux. La décision dépend des compétences de votre équipe, de ce que l’application doit faire et de ce que vous maintiendrez ensuite.

Oui. Nous séparons chaque texte du code afin qu’il puisse être traduit, et nous mettons en page avec des propriétés logiques pour que les pages s’inversent correctement dans les langues écrites de droite à gauche comme l’arabe. Les dates, les nombres et les devises suivent les conventions de chaque langue et région. Nous le prévoyons dès le départ, car ajouter une deuxième langue à une application conçue pour une seule représente beaucoup plus de travail.

Les applications natives en Swift et en Kotlin offrent l’accès le plus complet aux fonctionnalités de l’appareil et l’intégration la plus fidèle à chaque plateforme. Les applications multiplateformes en React Native ou en Flutter partagent l’essentiel de leur code entre iOS et Android, ce qui réduit le coût de développement et d’évolution. Nous recommandons le natif lorsque l’application dépend fortement de l’appareil, par exemple pour du matériel de paiement ou des médias complexes, et le multiplateforme pour la plupart des applications professionnelles et grand public.

Oui, lorsque les parcours le permettent. Nous stockons sur l’appareil, de façon chiffrée, les données dont l’utilisateur a besoin, et nous mettons ses modifications en file d’attente jusqu’au retour de la connexion. Des règles de synchronisation déterminent ce qui se passe lorsqu’un même enregistrement a été modifié à deux endroits. Nous définissons ces règles avec vous, car ce sont des décisions métier autant que techniques.

En général, celui que vous utilisez déjà, sauf raison claire d’en changer. Amazon Web Services, Microsoft Azure et Google Cloud exécutent tous trois très bien des charges de travail d’entreprise. Les facteurs décisifs sont vos contrats et compétences existants, les services managés dont vous avez besoin, les règles de localisation des données et la manière dont vos autres systèmes se connectent. Nous travaillons sur les trois et limitons le code propre à un fournisseur aux endroits où il en vaut la peine.

Nous utilisons les outils adaptés à votre pile technologique et à votre équipe : Playwright ou Cypress pour les tests web de bout en bout, Appium pour le mobile, Jest, JUnit ou pytest pour les tests unitaires, Postman pour les contrôles d’API, k6 ou JMeter pour la performance et OWASP ZAP pour les analyses de sécurité. Nous conservons les tests dans votre dépôt et, autant que possible, dans le langage de vos ingénieurs, afin qu’ils puissent les maintenir.

Nous utilisons l’environnement de test ou le bac à sable du partenaire lorsqu’il existe, et des simulateurs dans le cas contraire, pour que les tests puissent s’exécuter à chaque modification sans dépendre d’un tiers. Les données de test couvrent les cas d’échec : paiements rejetés, délais dépassés, messages en double et défaillances partielles. Des contrôles de bout en bout confirment que les totaux se rapprochent d’un système à l’autre, et pas seulement que chaque appel a renvoyé un succès.

Oui. Concevoir de droite à gauche ne consiste pas simplement à retourner l’écran. La navigation, les indicateurs de progression, les graphiques et les icônes qui suggèrent une direction doivent être inversés, alors que les nombres, les logos et les commandes multimédias ne le sont généralement pas. Le texte arabe exige sa propre police, sa propre taille et son propre interlignage. Nous concevons les deux sens ensemble et les faisons relire par des lecteurs natifs.

Un système de design est un ensemble partagé de couleurs, de typographies, d’espacements et de composants, assorti de règles d’usage, maintenu en cohérence entre les fichiers de design et le code. Il devient nécessaire lorsque plusieurs équipes ou plusieurs produits doivent avoir une apparence et un comportement cohérents, ou lorsqu’un produit va évoluer pendant des années. Pour un petit outil isolé, une bibliothèque de composants plus légère suffit souvent.

Lorsque l’ancien cœur est stable et correct, mais difficile d’accès. Des API modernes placées devant lui permettent aux nouveaux canaux, partenaires et produits d’utiliser ses fonctions sans toucher à son fonctionnement interne, avec un risque bien moindre qu’un remplacement. Nous recommandons le remplacement lorsque le système bloque le changement, ne peut pas être sécurisé ou ne trouve plus les compétences nécessaires.

Nous travaillons avec les piles technologiques sur lesquelles de nombreux systèmes de gestion ont été construits, notamment les anciennes versions de Java et de .NET, des bases de données relationnelles comme Oracle Database et SQL Server, des services SOAP et des interfaces à base de fichiers. Pour les plateformes plus rares, nous évaluons d’abord le code et vous disons franchement si nous disposons des compétences nécessaires, ou si un spécialiste doit rejoindre l’équipe.

Nous travaillons avec SAP S/4HANA et SAP Business One, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365 Finance and Supply Chain Management, Dynamics 365 Business Central, Odoo, Sage Intacct et Sage X3, ainsi qu’avec des systèmes sur mesure et plus anciens. Pour chacun, nous utilisons les interfaces prises en charge par l’éditeur, afin que les mises à niveau ne cassent pas l’intégration. La mention d’un produit ne signifie pas un partenariat avec son éditeur.

Pas toujours. Quelques flux stables entre deux systèmes peuvent reposer sur des appels d’API directs. Dès que plusieurs systèmes échangent des données, ou que vous avez besoin de centraliser la correspondance des données, les files d’attente et la supervision, un middleware comme MuleSoft, Boomi ou Azure Logic Apps est généralement rentabilisé. Si vous en possédez déjà un, nous nous appuyons dessus. Nous vous présentons les arbitrages, coûts de licence compris, avant que vous ne décidiez.

Nous travaillons avec les messages ISO 20022 que les banques utilisent pour les paiements et le reporting des entreprises : pain.001 pour les paiements, pain.002 pour les statuts, et camt.052, camt.053 et camt.054 pour les relevés de compte. Nous traitons aussi les relevés SWIFT MT940 et MT942 que de nombreuses banques envoient encore. Pour le transport, nous utilisons SFTP host-to-host, EBICS lorsque les banques le proposent, et les API bancaires. Chaque banque a sa propre variante de chaque format : nous développons donc à partir du guide de mise en œuvre de la banque, et non de la seule norme.

Nous connectons les banques à SAP S/4HANA, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Odoo et Sage, ainsi qu’aux systèmes de trésorerie et aux systèmes sur mesure. Certains ERP disposent de leurs propres modules de communication bancaire. Dans ce cas, nous les configurons et les étendons plutôt que de les contourner. La mention d’un produit sur cette page ne signifie pas un partenariat avec son éditeur.

Oui, lorsque l’acquéreur ou le processeur le propose. ISO 8583 est un cadre plutôt qu’un format unique : chaque acquéreur publie sa propre spécification des champs, des types de messages et de la gestion réseau. Nous développons à partir de cette spécification, traitons les autorisations, les annulations et les messages de notification (advice), et testons chaque code réponse. Lorsqu’une passerelle propose une API moderne devant l’acquéreur, nous recommandons souvent cette solution.

Nous intégrons les terminaux EMV à puce et sans contact via le protocole fourni par leur prestataire, généralement une API locale ou cloud entre la caisse et le terminal. Le terminal et son application de paiement sont certifiés par le prestataire : nous nous y intégrons donc sans les modifier. Nous confirmons avec vous et le prestataire, dès le départ, les modèles et protocoles exacts.

Cela dépend du nombre de liaisons et de l’équipe qui les exploitera. Une plateforme d’intégration comme MuleSoft, Boomi ou Azure Logic Apps réunit des connecteurs prêts à l’emploi, la correspondance des données et la supervision en un seul endroit, moyennant un coût de licence. Des services sur mesure vous donnent une maîtrise complète, sans licence, mais davantage de code à maintenir. Nous comparons les deux options pour votre cas et nous appuyons sur une plateforme que vous possédez déjà.

Nous étudions les limites publiées par chaque partenaire et concevons en conséquence : regroupement des requêtes lorsque l’API le permet, mise en cache des données qui changent rarement, étalement des tâches planifiées et ralentissement lorsque le partenaire signale qu’une limite est proche. La supervision indique l’écart entre chaque flux et sa limite, afin que la croissance ne se traduise pas en échecs.

En général, non. La plupart des banques ont davantage à gagner en encapsulant le core banking dans des API bien définies et en construisant de nouveaux produits et canaux sous forme de services autour de lui. Le système de référence reste ainsi stable, tandis que les parties visibles par les clients évoluent plus vite. Lorsqu’un core banking doit réellement être remplacé, nous planifions la migration par étapes, les deux systèmes étant rapprochés jusqu’à l’arrêt de l’ancien.

Oui. Nous développons des services qui créent, valident et lisent les messages ISO 20022, tant pour les paiements et le reporting des entreprises, comme pain.001 et camt.053, que pour les messages interbancaires utilisés par les systèmes de paiements instantanés et de paiements de montant élevé. Chaque schéma et chaque banque a ses propres règles : nous travaillons donc à partir de leurs guides de mise en œuvre et testons dans leurs environnements de test.

Oui. Nous combinons des règles que vos analystes peuvent lire et modifier avec des modèles d’apprentissage automatique entraînés sur vos propres données, et nous expliquons pourquoi chaque alerte a été levée. Les alertes rejoignent une file de dossiers où les analystes décident, et leurs décisions alimentent en retour les règles et les modèles. Si vous faites déjà appel à des fournisseurs spécialisés de filtrage, nous les connectons.

Le magasin continue de vendre. Les ventes sont stockées localement et transmises au retour de la connexion, chacune avec un identifiant unique pour que rien ne soit comptabilisé deux fois. Les mises à jour de prix et de stock sont mises en file d’attente de la même manière. L’exploitation voit quels magasins sont en retard et de combien, si bien qu’une coupure prolongée est repérée immédiatement, et non découverte à la clôture du mois.

Nous intégrons les plateformes POS par les moyens qu’elles offrent : API cloud, serveurs magasin, exports de base de données ou fichiers. Avant tout chiffrage, nous étudions la documentation du POS et un échantillon de ses données, car c’est ce qui détermine l’approche. La mention d’une plateforme POS ou d’un ERP sur ce site ne signifie pas un partenariat avec son éditeur.

Oui. Nous développons et maintenons des flux EDI en EDIFACT et en ANSI X12, via AS2, SFTP ou un réseau à valeur ajoutée, pour les commandes, les avis d’expédition, les factures et les messages de statut. Nous convertissons aussi l’EDI en API et en événements, afin que les systèmes plus récents n’aient pas à lire l’EDI eux-mêmes, et nous testons chaque flux avec le partenaire commercial avant sa mise en production.

Nous plaçons une couche transporteurs unique entre vos systèmes et les transporteurs. Vos systèmes réservent, étiquettent et suivent par une seule interface, et cette couche traduit chaque requête vers l’API ou le format de fichier de chaque transporteur. Ajouter un transporteur revient alors à ajouter une correspondance et ses tests, sans modifier chaque système expéditeur. Tarifs, étiquettes et événements de suivi reviennent dans un format unique.

Oui. Nous étendons les systèmes existants par leurs API, leurs interfaces de messages ou leurs bases de données, et ajoutons autour d’eux des outils mobiles et des intégrations. Si un système a atteint ses limites, nous planifions un remplacement progressif, les deux systèmes fonctionnant jusqu’à ce que le nouveau ait fait ses preuves.

Oui. Nous développons des interfaces qui envoient et reçoivent des messages HL7 v2, comme les admissions, les demandes d’examens et les résultats, ainsi que des services qui exposent ou consomment des ressources FHIR. Nous faisons correspondre les codes locaux aux terminologies attendues par vos partenaires, et nous testons avec leurs systèmes de test avant toute mise en production.

En général, oui, par les interfaces que fournit son éditeur : flux HL7 v2, API FHIR ou moteur d’intégration. Certains éditeurs exigent un enregistrement ou une validation avant la mise en production d’une intégration. Nous étudions la documentation de l’éditeur dès le début, car elle détermine le périmètre et le plan.

Nous concevons selon le niveau AA des WCAG 2.2 dès le premier prototype, rédigeons en langage clair et testons au clavier, avec des lecteurs d’écran et des outils d’agrandissement. Des contrôles d’accessibilité automatisés s’exécutent dans la chaîne de livraison et, avant les mises en production majeures, nous testons avec des personnes qui utilisent des technologies d’assistance.

Oui. De nombreux services publics reposent sur des systèmes en service depuis longtemps. Nous nous y connectons par leurs interfaces, fichiers ou bases de données existants, et plaçons devant eux une API moderne lorsque c’est utile. Si un remplacement s’impose, il se fait par étapes, les deux systèmes fonctionnant jusqu’à ce que le nouveau ait fait ses preuves.

Pas s’ils sont réalisés correctement. Nous utilisons les points d’extension pris en charge par l’ERP, comme les API, les événements et les frameworks d’extension, et séparons le code spécifique du produit standard. Chaque extension est documentée et testée, afin de pouvoir être vérifiée sur une nouvelle version avant la mise à niveau.

Nous travaillons avec SAP S/4HANA et SAP Business One, Microsoft Dynamics 365 Finance and Supply Chain Management et Business Central, Oracle NetSuite, Oracle Fusion Cloud ERP, Odoo, ainsi que Sage Intacct et Sage X3. La mention d’un produit ne signifie pas un partenariat avec son éditeur. Indiquez-nous votre version et vos modules, car ils déterminent les options d’intégration.

Oui. Nous concevons les intégrations pour gérer plusieurs entités juridiques, devises, banques et règles fiscales depuis une seule plateforme, les paramètres de chaque entité étant définis par configuration plutôt que dans le code. Ajouter une entité revient alors à ajouter de la configuration et des tests, et non une nouvelle intégration.

C’est généralement la banque qui décide. SFTP host-to-host est le canal le plus largement proposé pour les fichiers de paiement des entreprises. EBICS est répandu auprès des banques en Allemagne, en France et dans les pays voisins. Les API bancaires conviennent aux soldes en temps réel et aux virements instantanés lorsque la banque les propose. De nombreuses entreprises en utilisent plusieurs, et la couche d’intégration masque ces différences à l’ERP.

Lorsque la banque propose les deux, camt.053 transporte des informations de remise plus riches et structurées, ce qui fiabilise le rapprochement automatique. MT940 reste très utilisé et convient bien à de nombreux cas. Nous pouvons recevoir les deux, les convertir dans un même modèle interne, et faire passer chaque banque de MT940 à camt.053 au moment qui vous convient, à vous et à la banque.

Généralement sous forme d’événements en quasi temps réel, car les chiffres de stock et de ventes sont alors à jour en cours de journée. Certains ERP ou certaines licences rendent les comptabilisations fréquentes coûteuses : la couche peut donc aussi regrouper les événements en synthèses par magasin et par période. Nous choisissons avec vous en fonction des décisions qui exigent des données à jour et de ce que l’ERP traite bien.

L’architecture fonctionne avec tout système de caisse capable d’exporter ses transactions via une API, des événements ou des fichiers, et avec des ERP comme SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central et Odoo. Nous confirmons dès le départ les interfaces de votre système de caisse et de votre ERP. La mention d’un produit ne signifie pas un partenariat avec son éditeur.

L’acquéreur est la banque ou l’établissement agréé qui traite les paiements par carte pour votre compte et vous reverse les fonds. La passerelle est le service technique placé en amont, qui reçoit les demandes des terminaux et des pages de paiement, tokenise les cartes et les achemine. Certains prestataires assurent les deux rôles. L’architecture fonctionne dans les deux cas et maintient une séparation claire entre ces rôles.

Non. ISO 8583 définit une structure, et chaque acquéreur ou réseau publie sa propre spécification des champs, des types de messages et des codes. C’est pourquoi nous développons à partir de la spécification de l’acquéreur et exécutons ses tests de certification. Une API de passerelle placée devant l’acquéreur masque ces différences, ce qui est souvent plus simple pour les commerçants.

Un agrégateur vous donne accès à de nombreuses banques via une seule API et gère les particularités de chacune, moyennant un coût par appel ou par connexion. Les connexions directes offrent davantage de maîtrise et peuvent convenir pour un petit nombre de banques importantes. De nombreux produits démarrent avec un agrégateur et ajoutent ensuite des connexions directes. Nous comparons les options au regard des banques et des pays dont vous avez besoin.

La couverture dépend des règles de la région et des API des banques. L’Union européenne et le Royaume-Uni bénéficient d’une large couverture au titre de la DSP2 et du UK Open Banking Standard. Ailleurs, la couverture varie, et les agrégateurs comblent une partie des lacunes. Nous vérifions la couverture des banques utilisées par vos clients avant que vous ne vous engagiez sur une architecture.

Pas pour la plupart des activités de trésorerie d’entreprise. Les canaux host-to-host traitent les fichiers de paiement en masse et les relevés complets de vos propres comptes. L’open banking convient aux produits destinés aux clients, aux soldes en temps réel et aux paiements unitaires. De nombreuses entreprises utilisent les deux : le host-to-host pour leurs propres campagnes de paiements et l’open banking pour leurs clients.

Tout service doté d’une API ou d’une interface de fichiers documentée. Exemples courants : plateformes CRM, transporteurs et prestataires logistiques, places de marché, plateformes de facturation électronique et de fiscalité, paie, prestataires de KYC et d’identité, et partenaires commerciaux qui échangent des documents EDI sur AS2. Nous examinons l’API, les limites et l’environnement de test de chaque partenaire avant de nous engager sur un plan.

Dès que plusieurs partenaires sont connectés à un même ERP, une plateforme telle que MuleSoft, Boomi ou Azure Logic Apps, ou un ensemble de services spécifiques construits sur une file de messages, regroupe la transformation des données, les nouvelles tentatives et la supervision en un seul endroit. Avec un ou deux partenaires, des connexions directes peuvent suffire. Nous présentons les compromis, y compris le coût des licences, adaptés à votre situation.

XSIS est la société technologique de KONG GROUP. Nous concevons, développons, intégrons et exploitons des logiciels pour les entreprises : IA et données, logiciels sur mesure, web et mobile, cloud, ainsi que les intégrations qui connectent les ERP aux banques, aux points de vente et aux tiers. La fintech est notre secteur phare. Nous intervenons avec nos propres ingénieurs internes et des équipes externalisées sélectionnées, selon un même ensemble de standards.

Notre siège social se trouve à San Francisco, États-Unis. Nous avons également des bureaux à Hong Kong, à Tallinn, Estonie et à Dubaï, Émirats arabes unis. Nous convenons dès le départ des horaires de travail et des créneaux de réunion avec chaque client, afin que le recouvrement horaire convienne à votre équipe.

Décrivez votre besoin sur la page Contact et choisissez le créneau qui vous convient. Notre équipe vous appellera dans les 24 heures, sur le créneau de votre choix. Lors de ce premier échange, nous vous interrogeons sur vos systèmes, vos contraintes et votre calendrier, et vous proposons le mode de collaboration adapté. Si notre offre correspond à votre besoin, une proposition écrite suit.

Oui. Citer un produit sur ce site ne signifie pas un partenariat avec son éditeur, et notre recommandation suit vos exigences, vos compétences et votre budget, y compris lorsque conserver l’existant est la meilleure réponse. Si nous souhaitons réaliser nous-mêmes les travaux, nous le disons ouvertement, et le plan est rédigé de sorte que toute équipe compétente puisse le mettre en œuvre.

La fintech est notre secteur phare. Nous développons des applications de banque en ligne et de portefeuille électronique, des services de paiement et de règlement, des plateformes de crédit, du reporting patrimonial et des parcours d’assurance, et nous les connectons aux banques, aux processeurs de cartes, aux fournisseurs KYC et aux ERP. Nous ne publions pas le nom de nos clients sans leur accord : nous montrons donc notre expérience par les systèmes et les standards avec lesquels nous travaillons, et lors d’échanges techniques avec vos architectes.

Oui. Nous répondons aux appels d’offres et aux exigences des accords-cadres, et pouvons travailler sur un périmètre fixe ou par tranches, avec des critères d’acceptation écrits. Nous fournissons la documentation habituellement demandée par les acheteurs, comme les descriptions de sécurité, les plans de réalisation et les rôles nominatifs, et nous n’affirmons que ce que nous pouvons prouver. Lorsqu’un accord-cadre fixe ses propres conditions, nous travaillons dans ce cadre.

Notre cœur de métier est l’extension et l’intégration des ERP plutôt que leur mise en œuvre complète. Nous travaillons souvent aux côtés de votre intégrateur et prenons en charge les intégrations, la migration des données, les extensions spécifiques et les applications autour de l’ERP, afin que le projet principal tienne son planning.

L’information sur les comptes et l’initiation de paiement sont des activités réglementées dans de nombreux pays. Soit votre entreprise détient l’agrément, soit vous passez par un prestataire agréé qui le détient. Le cas applicable dépend de votre pays et de votre cas d’usage, et vos conseillers juridiques et conformité doivent le confirmer. Nous réalisons l’intégration quelle que soit la voie retenue.