Ce qui a été livré, et pour qui

Ce que contient l'application versionnée :

• Doctypes métier du réseau — partenaires, solutions, régions, contenus, prestations analytiques, demandes de devis événementiel, documents personnels
• Synchronisation depuis Airtable, avec cache et vues dédiées, pour reprendre les données déjà tenues par le réseau sans double saisie
• API, personnalisations et portails web propres au réseau
• Patches de migration, pour que les instances déjà en service suivent les évolutions du modèle de données

Le cycle de vie est modélisé tel quel, avec un statut visible de tous :

Ouverte	la campagne collecte les engagements
Objectif atteint	le seuil est franchi, la commande est viable
Complète	l'engagement est clos et la commande passée
Livrée	les participants sont servis
Expirée	l'échéance est tombée avant l'objectif

Autour de ce cycle : des pages de campagne publiques, consultables sans compte comme une page de collecte ; un panier en ligne pour se positionner ; l'acceptation des conditions générales au moment de l'engagement ; un circuit d'approbation des demandes, avec un indicateur de celles qui attendent une décision ; des règles d'expédition propres à ce mode de vente ; et un récapitulatif imprimable pour la préparation.

La difficulté de fond est que l'ERP sait vendre à un client. Ici, les engagements de plusieurs dizaines de participants s'agrègent en une commande unique auprès du fournisseur, à un prix qui dépend du volume atteint, puis se redistribuent en autant de livraisons individuelles. Rien dans le modèle commercial standard ne prévoit cet aller-retour, et c'est tout l'objet de l'application.

Le modèle de données. Sortir les ensembles de produits au profit d'une table de ressources liées, avec son éditeur en cartes et le patch qui migre les configurations existantes ; puis propager le nouveau modèle partout où l'ancien traînait encore — rapport de tarifs, dialogue de réservation d'événement, synchronisation Google Calendar, règles de conversion des crédits. Plus les correctifs de migration, pour que les instances déjà en production suivent sans perte, y compris celles restées sur des noms de doctypes de la version précédente.

L'interface du bureau. Nouvel espace de travail, nouvelle page d'accueil, barre latérale repensée, cartes de synthèse, parcours de prise en main, refonte visuelle des créneaux et des exceptions de disponibilité, assistants guidés pour la création de contrats, fusion des écrans de paramétrage redondants, jusqu'à l'icône de l'application.

Les tests. Une série de suites d'intégration ajoutées en amont de la refonte — système de crédits, planificateur de contrats, cycle de vie des badges, inscriptions aux événements, dépôts de garantie — pour refondre sur un filet plutôt qu'à l'aveugle.

Côté gestion, la présence se valide depuis l'inscription à l'événement ou en lot depuis l'événement lui-même, avec un dialogue qui nomme explicitement le badge sur le point d'être attribué. Le marquage de présence est un champ en lecture seule qu'on ne bascule que par cette action, et le serveur refuse de valider la présence à un événement qui n'a pas encore commencé.

Le compte utilisateur expose une section « Mes badges » avec les dates d'expiration et un avertissement trente jours avant l'échéance. Un badge expiré n'est pas effacé : il reste en historique, et une nouvelle attribution en émet un neuf.

Le système est inspiré de FabManager, avec une différence assumée : FabManager n'ouvre que la voie présentielle, là où le gestionnaire peut ici choisir la formation en ligne, le présentiel, ou les deux.

1. Étude de conformité, avant toute ligne de code. Statut de l'ERP au regard des obligations comptables et fiscales belges, arbitrage entre développer un connecteur et passer par un intermédiaire, traitement des factures transfrontalières, obligations propres aux ASBL. Sources vérifiées dans le texte de loi.

2. Un prototype, pour comprendre. J'ai développé un connecteur maison entre l'ERP et un opérateur d'accès au réseau. Il fonctionnait, et il m'a surtout appris ce que la chaîne demandait réellement.

3. La décision : ne pas le maintenir. Un connecteur propriétaire, c'est un composant réglementaire dont je serais seul responsable — à suivre à chaque évolution du réseau, des formats et des règles de validation, pour un seul client. J'ai abandonné mon prototype au profit d'une application libre émergente, edocument, portée par une autre équipe et déjà utilisée ailleurs. Moins de code à moi, une charge de maintenance partagée, et une trajectoire qui ne dépend pas de ma disponibilité.

4. Contribuer plutôt que contourner. Cette application n'était pas encore mûre. Plutôt que d'empiler des correctifs locaux chez mon client, j'ai remonté chaque problème en amont : 13 contributions fusionnées sur edocument, edocument_integration et eu_einvoice_peppol. Chacune corrige un problème rencontré en production sur des flux réels, et profite à tous les utilisateurs de ces applications — y compris à moi, la prochaine fois.

Une contribution résume l'ensemble. La première facture de l'exercice part sur le réseau en portant l'identifiant technique de son brouillon au lieu de son numéro définitif. Trois réponses, dans cet ordre : régulariser la situation du client depuis l'interface de l'opérateur, sans écriture fictive dans une comptabilité qui était juste ; vérifier dans le texte ce que la réglementation autorise en pareil cas plutôt que de le supposer ; puis corriger la cause en amont, pour que le problème ne se reproduise ni chez ce client ni chez personne d'autre.

• Plan comptable minimum normalisé (PCMN), versions commerciale et ASBL, en français et en néerlandais. Intégré en amont dans ERPNext, donc disponible pour tout l'écosystème.
• Catalogue officiel des 30 grilles TVA et correspondance grille par grille avec les taux, y compris l'éclatement des opérations en autoliquidation.
• Génération du fichier XML INTERVAT, validé contre les schémas publiés par le SPF Finances, puis éprouvé sur l'environnement de test du portail avant tout dépôt réel.
• Extraction multi-taux depuis la comptabilité générale, en repartant de la TVA effectivement comptabilisée plutôt que d'un recalcul parallèle — la seule méthode qui résiste à un contrôle.

Ajouté en amont dans ERPNext au passage : les taux de TVA belges à 0 % et 6 %.

L'environnement est monté dans l'application de démonstration de Dokos : module de certification caisse installé et configuré (licence, SIREN, enregistrement auprès du serveur d'archivage sécurisé), profil de point de vente, format de ticket, articles et atelier permettant de dérouler des ventes réelles, et intégration à la chaîne d'intégration continue pour que la démo parte toujours d'un état vérifié. Le paramétrage est idempotent : il se rejoue autant de fois que nécessaire avant le passage de l'auditeur.

Le message dit quoi faire, pas ce qui s'est passé. Sur l'exemple ci-dessus, la passerelle n'a jamais confirmé et les vérifications automatiques se sont arrêtées. Le message n'annonce donc pas « échec » — il avertit que la somme a peut-être déjà été encaissée et invite à vérifier avant de redemander le paiement. C'est exactement l'erreur coûteuse qu'un comptable pressé commettrait, et le bouton d'action ouvre le signalement de rapprochement plutôt que de relancer le client.

Une seule lecture pour toutes les passerelles. L'affichage ne s'appuie que sur le socle commun aux passerelles de paiement de Dokos — Stripe, GoCardless, PayPal, Braintree, Stancer, HelloAsso, Lyra. Aucun cas particulier par prestataire à écrire ni à maintenir, et une passerelle ajoutée demain hérite du même suivi sans une ligne de plus.

• Correction de la date de prélèvement SEPA (ReqdColltnDt, message ISO 20022 pain.008), qui reprenait une date inadaptée et faisait rejeter des remises.
• Résolution d'un interblocage à la génération des fichiers de prélèvement.
• Rapprochement des paiements Stripe SEPA, dont les transactions de type payment n'étaient pas appariées.
• Rapprochement bancaire : colonnes configurables, présélection du compte par défaut, correspondance des références insensible à la casse, correction du filtre par période, traitement des avoirs.
• Synchronisation bancaire automatique planifiée sur une instance en production, là où l'import ne se déclenchait que manuellement.

Sur le connecteur Dokos Hiboutik, j'ai mené le premier déploiement en clientèle et contribué au code à cette occasion : synchronisation des clients, et statut de règlement erroné sur les factures validées sans paiement.