Technologie et ingénierie
Chaque couche technique. Un seul système.
Grumpio conçoit le trading, les ledgers, les wallets, les paiements, l’AML/KYC, les applications mobiles, l’exploitation back-office et l’infrastructure de production comme une seule plateforme, avec la performance, la sécurité et la préparation réglementaire intégrées au modèle de livraison.
Ingénierie fintech de bout en bout
Pas un catalogue de services
Grumpio entretient une capacité d’ingénierie couvrant l’ensemble du spectre technique de la fintech – des ledgers et moteurs de matching jusqu’au SIEM et au pilotage de programme. Rien de tout cela n’est proposé comme une prestation d’agence isolée. Chaque discipline existe parce qu’un produit Grumpio en a besoin en production, et chacune a été conçue avec la réglementation, la performance, la sécurité et la continuité comme données d’entrée, non comme des considérations tardives.
Cœur financier
Ledger en partie double (comptabilité en partie double), rapprochement, settlement et enregistrements de protection des fonds (safeguarding) pour les produits d’actifs numériques et de monnaie électronique.
Infrastructure de trading
Systèmes de plateforme d’échange d’actifs numériques et moteurs de matching à haut débit, décrits sous l’angle produit sur la page logiciel de plateforme d’échange crypto.
Blockchain et wallets
Connectivité aux nœuds, modèles de wallets et infrastructure de gestion des clés pour l’exploitation d’actifs numériques.
AML, KYC et risque
Workflows de filtrage, de vérification et de risque blockchain intégrés au flux transactionnel, avec le logiciel de contrôle AML comme couche produit définie.
Applications et back-office
Applications web, iOS et Android, ainsi que l’outillage d’administration, livrés comme partie intégrante du produit et non acquis séparément.
Exploitation en production
DevOps, sécurité de l’information, journalisation centralisée et SIEM, ainsi que l’ingénierie de préparation à l’audit qu’exige une exploitation régulée.
Systèmes financiers et ledger
La partie double au cœur du système
Les mouvements financiers sont tenus en partie double, avec un historique de transactions auditable, plutôt que par des champs de solde modifiables. Le solde affiché à l’écran est une projection ; le ledger sous-jacent enregistre le cycle de vie de chaque transaction et chaque mouvement entre comptes, de sorte que le rapprochement et les éléments de preuve d’audit sortent du système lui-même au lieu d’être reconstitués après coup.
Les enregistrements de protection des fonds, les écritures de settlement et l’historique d’audit immuable suivent la même discipline sur le logiciel de monnaie électronique et les produits d’actifs numériques.
- Ledger en partie double : une écriture n’existe jamais seule ; la contrepartie est toujours enregistrée, et le cycle de vie de la transaction reste traçable de bout en bout.
- Soldes disponibles et en attente : les fonds utilisables par le client et les fonds en attente d’exécution sont tenus séparément, les blocages et réserves cantonnant les montants sous un contrôle défini.
- Rapprochement : les enregistrements internes sont produits sous une forme qui peut être confrontée aux enregistrements des contreparties externes.
- Multidevise : les monnaies fiat et les actifs numériques résident dans la même structure d’enregistrement plutôt que dans des systèmes parallèles.
- Moteurs de frais et de limites : chaque frais appliqué ou modification de limite est enregistré, et les règles elles-mêmes sont gérées depuis un seul endroit.
- Enregistrements de settlement et de protection des fonds : les structures d’enregistrement prennent en charge le modèle de protection des fonds du client.
- Historique d’audit immuable : les transactions passées ne peuvent pas être réécrites silencieusement ; l’historique est conservé comme élément de preuve.
Trading et traitement en temps réel
Les événements portent la charge
Les flux financiers à haut volume sont coordonnés par des systèmes d’événements et de messagerie plutôt que de dépendre d’un seul chemin applicatif synchrone. L’idempotence, l’ordonnancement et les contrôles des doublons maintiennent ces flux corrects sous charge, et le suivi d’état les garde exploitables pour le reporting. Les types d’ordres, la capacité de matching et le périmètre du module de trading relèvent du produit ; ils sont traités sur la page logiciel de plateforme d’échange crypto.
-
REST, WebSocket et webhooks
Les intégrations clients et partenaires sont servies par des API REST, la diffusion en temps réel passe par WebSocket, et les webhooks poussent les événements vers les systèmes connectés.
-
Discipline d’ingénierie des API
Authentification sécurisée, autorisation, idempotence, gestion des erreurs, limitation de débit, versionnage et auditabilité sont traités comme des exigences de chaque interface, non comme des options.
-
Workflows financiers asynchrones
Les files d’attente et les traitements en arrière-plan absorbent le volume, les reprises sont contrôlées, et la cohérence à terme est gérée délibérément afin que les enregistrements restent fiables pour l’audit.
Blockchain et wallets
Nœuds, wallets, gestion des clés
L’infrastructure de wallets peut être configurée autour de modèles hot, cold, multisignature, HSM et de gestion cloisonnée des clés. La manière dont les clés sont générées, fragmentées, signées et récupérées est volontairement absente de cette page : la publier affaiblirait les contrôles mêmes sur lesquels les clients s’appuient. L’ingénierie des contrats intelligents et des tokens dispose de son propre périmètre sur la page contrats intelligents et tokenisation.
Connectivité nœuds et RPC
Des nœuds propres au client, des fournisseurs RPC tiers et un modèle propriétaire d’orchestration multi-fournisseurs peuvent être combinés ; dans des conditions de trafic et de fournisseurs adaptées, l’approche multi-fournisseurs peut aussi réduire le coût de connectivité.
Modèles de wallets
Les niveaux hot et cold, les dispositifs multisignature et l’intégration de dépositaires sont configurés selon le modèle de risque de l’opérateur plutôt que livrés comme une configuration par défaut.
Méthodes de gestion des clés
La multisignature Safe Protocol, des HSM basés sur Ledger ou choisis par le client, Vault et le partage de secret de Shamir X-of-Y sont disponibles, exploités sous des permissions cloisonnées.
Architecture des données et des événements
Une couche de données conçue à dessein
Chaque technologie de la couche données et messagerie tient un rôle défini. Les schémas, index, partitions, la réplication et la rétention restent des détails d’implémentation confidentiels ; ce qui peut être énoncé publiquement, c’est quel magasin de données porte quelle responsabilité.
PostgreSQL
Contient les enregistrements financiers, produit et opérationnels – le socle transactionnel sur lequel repose la couche ledger.
Redis
Fournit le cache, l’état transitoire et le support de workflow aux services qui manipulent des données éphémères.
OpenSearch
Répond aux requêtes de recherche, de logs, d’audit et d’investigation opérationnelle – le magasin vers lequel les équipes se tournent quand quelque chose doit être expliqué.
TimescaleDB
Accueille les séries temporelles, les métriques et les données historiques, en gardant interrogeables les enregistrements de long terme.
MinIO / S3
Conserve documents, rapports et artefacts dans un stockage objet compatible S3, y compris au sein d’environnements contrôlés par le client.
Kafka et RabbitMQ
Assurent la messagerie inter-services, l’event sourcing et les traitements en file d’attente, WebSocket prenant en charge la diffusion en temps réel vers les clients.
Langages de programmation
Cinq langages, des rôles définis
Go, Python, Node.js/TypeScript, JavaScript et Solidity sont les langages dans lesquels Grumpio livre ses produits. Le tableau présente le domaine d’emploi habituel de chacun. Il est indicatif et non exhaustif – il ne signifie pas que chaque produit utilise chaque langage – et la correspondance précise entre services et langages varie selon le produit et le déploiement.
| Langage | Usage typique |
|---|---|
| Go | Services financiers, de ledger, de transaction et d’intégration à haute performance. |
| Python | AML/KYC, traitement de données, automatisation, risque et exploitation. |
| Node.js / TypeScript | API, services produit, administration et intégrations. |
| JavaScript | Interfaces web et applications clientes, avec des frameworks frontend modernes. |
| Solidity | Développement de tokens, de contrats intelligents et blockchain. |
Web, mobile et administration
Les interfaces font partie de la plateforme
Les applications web, iOS et Android ainsi que la couche d’administration font partie du périmètre produit et sont développées selon le même modèle de livraison que les services backend. Ce que voient les utilisateurs finaux et les opérateurs est construit par l’équipe qui a construit le ledger sous-jacent ; la structure des enregistrements, les permissions et le comportement restent alignés à mesure que le produit évolue.
Applications web
Les applications web destinées aux clients sont construites avec des frameworks frontend modernes et adaptées à la marque de l’opérateur dans le modèle en marque blanche.
iOS et Android
Les applications iOS et Android sont livrées dans le même plan projet et se connectent à la même structure d’enregistrements que l’application web.
Administration et back-office
L’outillage opérateur est livré avec la plateforme ; l’autorisation basée sur les rôles et les enregistrements d’audit gouvernent ce que les administrateurs peuvent voir et faire.
Déploiement en production
L’infrastructure aux conditions du client
La plateforme n’est liée à aucun fournisseur cloud en particulier. Le déploiement suit les exigences réglementaires, de résidence des données, de coût et d’exploitation du client. L’architecture est de même choisie projet par projet – selon le type de produit, le volume de transactions, la réglementation, la taille de l’équipe d’ingénierie, les intentions de transfert et le coût d’exploitation – plutôt qu’imposée comme un schéma uniforme.
-
Conteneurs et Kubernetes
Les workloads sont conteneurisés avec Docker et s’exécutent sous Kubernetes lorsque le projet le requiert, ce qui garde les environnements reproductibles.
-
CI/CD avec des points de contrôle automatisés
Les releases progressent dans des pipelines CI/CD où les tests automatisés font office de point de contrôle, et le déploiement reste un processus maîtrisé et documenté.
-
Options d’environnement
On-premises, cloud privé, AWS, Microsoft Azure, Google Cloud Platform, Hetzner et centres de données dédiés sont des environnements cibles pris en charge, y compris les configurations à centre de données primaire et secondaire.
Sécurité et observabilité
La sécurité sur tout le cycle de vie
La sécurité est traitée à travers le code, l’identité, les données, l’infrastructure, le déploiement et l’exploitation. Elle traverse le cycle de vie comme une préoccupation d’ingénierie plutôt que comme une revue finale avant le lancement. Les événements clients, administrateurs, financiers et systèmes peuvent être surveillés et restitués de manière centralisée pour l’exploitation et l’audit.
- Ingénierie sécurisée : la revue de code ainsi que la gestion des dépendances et des vulnérabilités fonctionnent comme des contrôles de routine, non comme des mesures exceptionnelles.
- Contrôle d’accès : l’autorisation basée sur les rôles et la gestion des secrets maintiennent les opérations privilégiées restreintes et traçables.
- Chiffrement : le chiffrement est appliqué aux données en transit et au repos.
- Logs et enregistrements d’audit : les événements sont collectés de manière centralisée, avec la corrélation à disposition des opérations de sécurité et les éléments de preuve à disposition de l’audit.
- Coordination des tests d’intrusion : des tests indépendants sont planifiés avec des tiers spécialisés dans le cadre du programme de sécurité.
- Mises à jour et réponse à incident : les mises à jour de sécurité et les processus de réponse à incident sont définis avant d’être nécessaires.
Continuité et reprise
Une reprise exercée, non supposée
La sauvegarde est conçue conjointement avec les tests de restauration, les RTO/RPO et les environnements d’exploitation alternatifs. Une copie qui n’a jamais été restaurée ne prouve rien ; le chemin de reprise est donc exercé plutôt que supposé. Le périmètre, le calendrier, la rétention et les copies hors site sont arrêtés projet par projet, et les preuves de restauration sont conservées sous une forme sur laquelle les audits peuvent s’appuyer.
Automatisées, chiffrées, immuables
Des sauvegardes planifiées et chiffrées constituent le socle ; ce sont les copies immuables qui en font des éléments de preuve.
Tests de restauration
Les procédures de reprise sont testées de manière récurrente, de sorte que la restauration est une opération pratiquée plutôt qu’une première tentative sous pression.
Centres de données primaire et secondaire
Les cibles de bascule sont prévues dès la conception : les configurations à centre de données secondaire font partie de l’architecture, et la planification RTO/RPO fait partie du programme de continuité.
Tests et qualité
Validé avant la mise en production
Le logiciel est livré comme un système de production validé sur les intégrations, la charge, la sécurité et la régression, et non comme un code qui ne fonctionne qu’en environnement de développement. Le parcours ci-dessous correspond au déroulement d’une release type ; la profondeur des tests et le suivi de couverture sont définis projet par projet et partagés avec l’équipe technique du client.
-
Vérification fonctionnelle
Les règles métier sont éprouvées par des tests unitaires, d’intégration et de bout en bout avant toute autre étape.
-
Charge et stress
Le système est poussé au-delà du volume attendu afin que son comportement sous contrainte soit connu avant que les clients n’y soient confrontés ; les résultats alimentent la planification de capacité.
-
Sécurité et régression
Les suites de régression et de sécurité protègent chaque build candidat, avec une couverture dédiée au niveau des appareils pour les applications iOS et Android.
-
Staging et UAT
Les releases candidates sont validées dans des environnements de staging et de recette utilisateur au regard des critères de release du projet.
-
Release et rollback
La validation de release, la vérification du rollback et les smoke tests en production bouclent le cycle à chaque déploiement.
AI-Friendly Codebase
Cartographié, documenté, encadré
Les bases de code Grumpio sont structurées pour un usage sûr par les outils de développement assisté par IA – et, tout aussi important, pour une orientation rapide des ingénieurs humains. Une carte de projet lisible par la machine relie services, fichiers et responsabilités à travers la base de code. Ce que l’assistance par IA peut toucher est délimité : les zones critiques – finance, wallets, sécurité, ledger et réglementaire – exigent toujours une revue humaine.
- Neural-node mapping : les relations entre fichiers, modules et services sont extraites et rendues navigables pour les équipes d’ingénierie et les agents IA.
- Contexte et garde-fous : les composants financiers et de sécurité critiques contiennent le contexte et les garde-fous destinés à réduire les modifications assistées par IA non sûres.
- Fichiers de connaissance projet : la documentation d’architecture, les décisions de conception, les cartes de modules et les fichiers d’instructions IA accompagnent le code comme livrables.
- Là où l’assistance par IA s’insère : avec les permissions adéquates et une revue humaine, les outils d’IA peuvent accélérer la découverte du dépôt, la documentation, les tests, l’analyse d’erreurs et l’intégration des développeurs.
Propriété du code source et transfert
La propriété, pas la dépendance
Dans les missions enterprise avec code source, la plateforme est documentée et transférée de façon que l’équipe d’ingénierie du client puisse en prendre la responsabilité. La finalité du transfert est l’indépendance : après la transition, le client peut exploiter, maintenir et faire évoluer le système avec ses propres ingénieurs. L’accès aux dépôts, la documentation de déploiement, la formation et le plan de transition sont détaillés dans les supports commerciaux et contractuels, non sur cette page.
Équipes techniques
Des ingénieurs au sein de la mission
Les projets peuvent inclure des rôles techniques dédiés aux côtés du logiciel lui-même, selon des modèles à temps plein, périodiques, intégrés, en équipe managée ou au projet. La structure de l’équipe est confirmée lors du cadrage, au regard du travail réellement en jeu et de la capacité dont le client dispose déjà.
- Construire : des capacités de développement backend, frontend et mobile, placées là où la feuille de route produit en a besoin.
- Exploiter : DevOps, ingénierie de sécurité et management de la sécurité de l’information pour le parc de production.
- Piloter : architecture de solution et gestion de projet technique, qui portent ensemble les décisions techniques et le plan de livraison.
Prochaine étape
Commencer par une session technique
Une session technique réunit les ingénieurs de Grumpio et ceux du client autour de la même table : orientation d’architecture, choix d’environnements, attentes de transfert et structure d’équipe, discutés au regard du projet concret plutôt que dans l’abstrait.