Données produits · e-commerce Un catalogue multilingue qui reste juste chaque jour
Notre propre e-commerce (Bopets) vend sur .be, .nl et .eu, avec 11.422 produits en 6 versions linguistiques issus de dizaines de fournisseurs.
- Problème
- Les données fournisseurs arrivent dans des dizaines de formats et sont rarement prêtes à vendre : champs manquants, doublons, changements de prix et de stock.
- Approche
- Notre service géré CatalogOps importe les fichiers, associe et enrichit, bloque les exceptions pour contrôle humain et ne publie qu'après approbation.
- Architecture
- Fournisseurs → CatalogOps → Odoo (données maîtres) et WooCommerce (boutique), avec une synchronisation contrôlée quotidienne.
- Ce qui reste géré
- Les runs quotidiens, le suivi des erreurs et les mappings tournent en continu ; une nouvelle version fournisseur devient un contrôle planifié plutôt qu'une crise.
CatalogOpsOdooWooCommerceGS1 / GPSR
Web & SEO · réseau de contenu Un réseau propre de plus de 90 sites multilingues
Depuis 2004, nous construisons et gérons un réseau de plus de 90 sites, multilingues et transfrontaliers.
- Problème
- Gérer de façon fiable contenu, multilinguisme, vitesse et visibilité sur de nombreux sites à la fois, sans que la maintenance devienne ingérable.
- Approche
- Une base partagée et maintenable avec hreflang et i18n corrects, des Core Web Vitals rapides et un flux de publication et de gestion répétable.
- Architecture
- Des frontends modernes, en grande partie statiques (dont Astro) derrière Cloudflare, sur une infrastructure gérée en interne.
- Ce qui reste géré
- Hébergement, mises à jour, monitoring et sauvegardes tournent en continu ; ce site (vimm.be) repose sur la même approche.
AstroCloudflarehreflang & i18nCore Web Vitals
Infrastructure · continuité Une infrastructure gérée en interne, avec redondance et sauvegardes
Nous exploitons nos propres environnements de production non pas en revendant, mais en les mettant en place et en les gérant nous-mêmes.
- Problème
- Des environnements de production qui doivent rester rapides, disponibles et récupérables, sans dépendance à un fournisseur fermé.
- Approche
- Une stack gérée avec conteneurs, haute disponibilité au besoin, sauvegardes quotidiennes testées et monitoring avec alertes.
- Architecture
- De l'edge (Cloudflare) à la base de données : Coolify et Docker sur une infrastructure UE (Hetzner), avec sauvegarde hors site.
- Ce qui reste géré
- Mises à jour, patching, monitoring, sauvegardes et restauration tournent en continu ; nous connaissons migrations et bascules de première main.
CoolifyDockerHetzner (UE)Cloudflare
Systèmes métier · intégrations Un noyau ERP unique pour plusieurs marques et pays
Pour un groupe commercial international avec plusieurs marques, pays et canaux de vente, les commandes, les stocks et la facturation transitaient par des systèmes qui se comprenaient mal.
- Problème
- Des systèmes séparés par marque et par pays, double saisie et transferts manuels entre boutiques, comptabilité et logistique.
- Approche
- Un noyau Odoo en multi-company, avec des connexions API vers boutiques, services de paiement, marketplaces et flux externes.
- Architecture
- Boutiques et marketplaces → couche d'intégration → Odoo (commandes, stocks, facturation), avec retour de statut et de stock.
- Ce qui reste géré
- Les connexions et flux sont surveillés ; un nouveau canal ou une nouvelle marque devient une extension, pas un nouvel îlot.
OdooIntégrations APIEDI & fluxServices de paiement
Infrastructure · communication La téléphonie de plusieurs pays sur un central géré
Une organisation présente dans plusieurs pays européens avait une téléphonie fragmentée : une solution propre par pays, sans gestion centrale ni plan de numérotation cohérent.
- Problème
- Téléphonie séparée par pays, aucune vue centrale, et des numéros et renvois qui ne convergeaient nulle part.
- Approche
- Un central téléphonique géré en interne (Asterisk/FreePBX) avec des trunks SIP par pays et des passerelles GSM au besoin, et un plan de numérotation structuré.
- Architecture
- Trunks SIP et passerelles GSM → central (Asterisk) → postes et règles de renvoi par site, avec monitoring.
- Ce qui reste géré
- Le central, les trunks et le routage sont surveillés et ajustés ; un nouveau site ou pays se raccorde au même dispositif.
Asterisk / FreePBXSIP-trunkingVoIP & passerelles GSMMonitoring
Données produits · visibilité Garder des milliers de produits trouvables sur plusieurs pays
Pour une boutique avec des milliers de produits sur plusieurs pays et langues, un catalogue correct ne suffit pas : prix, stock et produits doivent aussi rester rapidement trouvables dans les moteurs de recherche et les marketplaces.
- Problème
- Les changements de prix, de stock et d'assortiment étaient repris lentement ; les flux et moteurs accusaient un retard sur le catalogue réel.
- Approche
- Des flux produits structurés, des sitemaps multilingues corrects et l'instant indexing, pour transmettre les changements rapidement plutôt que d'attendre.
- Architecture
- Catalogue → flux et sitemaps → moteurs et marketplaces, avec des pings d'instant indexing à chaque changement pertinent.
- Ce qui reste géré
- Flux, sitemaps et indexation sont surveillés ; les nouveaux produits et changements suivent automatiquement le même chemin.
Flux produitsIndexNowSitemaps XMLSearch Console & Bing
Migration · continuité D'une plateforme fermée vers une infrastructure gérée en interne
Une organisation était bloquée sur une plateforme fermée et coûteuse et voulait passer à une infrastructure gérée en interne, sans perdre l'exploitation, les données ni la visibilité.
- Problème
- Migrer un environnement live sans longue interruption, sans perte de données et sans casser les URLs et positions existantes.
- Approche
- Migration par phases avec un environnement parallèle, des sauvegardes testées, le maintien des URLs via redirections et une bascule DNS planifiée.
- Architecture
- Ancien environnement → reconstruction parallèle sur infra gérée en interne → bascule contrôlée, avec plan de repli.
- Ce qui reste géré
- Après la bascule, hébergement, monitoring et sauvegardes continuent ; l'organisation ne dépend plus d'un seul fournisseur fermé.
Migration & basculeRedirectionsSauvegarde & restaurationDNS
Automatisation IA · gouvernance Un assistant IA qui agit dans des limites strictes
Pour la gestion d'un environnement Microsoft 365 de plus de 1000 utilisateurs, nous avons construit pour nous-mêmes un assistant IA qui prend en charge le travail de routine, mais n'agit jamais vers l'extérieur sans contrôle.
- Problème
- Une IA qui touche au courrier, aux contacts et à la gestion des utilisateurs n'est utilisable que si elle n'exécute pas seule des actions irréversibles ou externes.
- Approche
- Un modèle de permissions à trois niveaux : lecture et tri autonomes ; confirmation pour les modifications ; approbation explicite avec dry-run pour les actions externes comme l'envoi de courrier ou la gestion des licences.
- Architecture
- Couche IA → contrôle des permissions → Microsoft 365, boîtes mail et contacts (Graph, IMAP, CardDAV), avec une piste d'audit complète de chaque action autonome.
- Ce qui reste géré
- Humain dans la boucle sur chaque action externe, tout est journalisé. R&D interne, pas un produit vendu : cela montre comment nous construisons une IA avec contrôle et auditabilité.
Claude AIMicrosoft 365 / GraphIMAP & CardDAVJournalisation
Données · reporting Rassembler les chiffres opérationnels dans un tableau de bord actuel
Dans une organisation, les chiffres opérationnels étaient dispersés entre plusieurs systèmes, sans une vue unique, actuelle et partagée pour la direction.
- Problème
- Les rapports étaient assemblés manuellement à partir de sources séparées ; une fois prêts, les chiffres étaient déjà dépassés.
- Approche
- Des pipelines de données (temps réel au besoin, batch quand c'est possible) qui rassemblent les sources, les nettoient et alimentent des tableaux de bord clairs.
- Architecture
- Systèmes sources → ETL et validation → couche de données → tableaux de bord pour la direction et les opérations.
- Ce qui reste géré
- Les pipelines et définitions sont surveillés ; une nouvelle source ou métrique s'ajoute sans casser la vue d'ensemble.
Pipelines ETLValidation des donnéesTableaux de bordSources API
Santé · collaboration Une plateforme de coordination des soins et de suivi des patients
Pour un contexte de soins, nous avons construit une plateforme qui soutient les parcours patients et la collaboration entre soignants, avec une attention à la confidentialité des données sensibles.
- Problème
- La coordination et le suivi passaient par des canaux et documents épars, sans flux structuré et partagé.
- Approche
- Une application web avec des parcours patients clairs, des rôles et droits d'accès, et la collaboration entre soignants concernés.
- Architecture
- Frontend web → couche applicative avec accès basé sur les rôles → modèle de données de santé, avec attention à la confidentialité et à la journalisation.
- Ce qui reste géré
- Accès, confidentialité et gestion des données restent centralisés ; de nouveaux parcours s'appuient sur le même modèle.
Application webAccès par rôlesModèles de données de santéPrivacy by design
Infrastructure · contrôle Un seul panneau de contrôle pour plusieurs environnements et déploiements
Pour ne pas gérer plusieurs applications et environnements un par un et à la main, nous avons construit notre propre panneau de contrôle avec vue d'ensemble et actions de déploiement.
- Problème
- L'état des environnements et les actions de déploiement étaient dispersés ; la vue d'ensemble et les opérations demandaient trop de travail manuel.
- Approche
- Un control-plane qui montre l'état actuel des environnements et regroupe les actions de déploiement et de gestion contrôlées au même endroit.
- Architecture
- Tableau de bord → couche d'orchestration → plusieurs cibles et environnements, avec retour d'état.
- Ce qui reste géré
- Le panneau et l'orchestration évoluent ; un nouvel environnement ou cible se raccorde à la même commande.
Node.js & ReactOrchestrationContrôle de déploiementMonitoring
