Système d'information

Une architecture décrit des composants. Un système d'information décrit comment ils tiennent ensemble : par où l'on entre, qui fait quoi, ce qui est calculé au centre, ce qui est conservé, et ce qui sort vers l'extérieur. C'est la vue que réclament un auditeur, un régulateur ou un futur repreneur — et c'est celle qui manque le plus souvent.

Les canaux d'accès

Six portes d'entrée, un seul système derrière. L'application web et les deux applications mobiles servent le guichet ; le portail agence donne à chaque point de vente son espace ; le portail client ouvre la consultation et le suivi ; l'interface d'administration reste séparée des trois autres.

Aucune de ces portes ne possède ses propres données. Elles lisent et écrivent toutes dans le même socle — c'est ce qui rend impossible l'écart entre ce que voit un caissier et ce que voit son directeur.

Les utilisateurs du système

Votre cahier des charges définit onze rôles. La carte ci-dessus en montre les dix profils qui accèdent directement au système ; le tableau ci-dessous précise, pour les principaux, la responsabilité de données qui leur est attachée — et pas seulement des droits d'écran.

La règle qui les lie : celui qui saisit n'est jamais celui qui valide. Au-delà d'un seuil paramétrable, une seconde signature est exigée — et elle est enregistrée.

Les six familles de modules

Elles découpent le système en frontières nettes : opérations financières, réseau et trésorerie, finance et comptabilité, risque et conformité, données et intelligence, paramétrage et administration.

Ce découpage n'est pas une commodité de présentation — ce sont les frontières internes du code et l'organisation du dépôt que vous recevrez. Le détail de chaque module figure sur la page dédiée.

Le cœur du SI : la couche de services communs

C'est le niveau que les schémas omettent le plus souvent, et c'est celui qui décide de la cohérence de l'ensemble. Moteur de règles métier, gestion transactionnelle en ACID, workflows, notifications, documents, messagerie, reporting, cache.

Chacun de ces services est écrit une fois et appelé par les six familles. Une règle de commission n'existe donc qu'à un seul endroit : la changer la change partout, sans qu'il faille se souvenir des modules qui l'utilisaient.

Les données : une seule écriture, N lectures

Toutes les données d'AiO ne se valent pas. Les confondre est l'erreur qui produit ces systèmes où le tableau de bord affiche un chiffre et la comptabilité un autre.

Nous en distinguons quatre natures, chacune avec ses propres règles :

Les référentiels se modifient, mais s'historisent. Un barème de commission change ; celui d'il y a six mois doit rester lisible, sinon une commission ancienne devient inexplicable. Un taux de change se met à jour ; l'opération d'hier se relit au taux d'hier. On ne modifie jamais un référentiel — on en crée une nouvelle version.

Le transactionnel s'écrit une fois et ne bouge plus. C'est le cœur. Une écriture comptable, une session de caisse close, une opération validée : aucune de ces données n'est modifiable. Une correction crée une nouvelle donnée liée à l'ancienne.

Les journaux ne font que s'ajouter. Le journal d'audit est chaîné cryptographiquement : chaque ligne porte l'empreinte de la précédente. Toute altération d'un historique casse la chaîne et devient détectable — par vous, ou par un auditeur externe qui n'a pas à vous faire confiance.

Le dérivé est jetable. Soldes, balances, statistiques, tableaux de bord, projections : tout se recalcule depuis les écritures. C'est ce qui rend impossible l'écart classique entre ce qu'affiche l'écran et ce que dit la comptabilité — puisque l'écran est la comptabilité, lue autrement.

Conservation et purge

Les durées ne sont pas décoratives : elles répondent à des obligations réglementaires qui varient d'un pays à l'autre.

• Écritures comptables : conservation permanente. Elles ne se purgent jamais.
• Opérations, dossiers clients, pièces justificatives : dix ans après la dernière opération, ajustable par pays.
• Journal d'audit : dix ans, inaltérable.
• Journal technique : quatre-vingt-dix jours. Il ne contient jamais de donnée client en clair.
• Données dérivées : aucune conservation. Elles se recalculent.

Une purge n'efface jamais une écriture : elle archive les données périphériques dont la durée légale est échue, en conservant la trace de la purge elle-même.

Sécurité & contrôle

Authentification forte, rôles, chiffrement en transit et au repos, traçabilité immuable, supervision, continuité. Le détail figure sur la page Sécurité & conformité.

Un point mérite d'être isolé ici, parce qu'il conditionne la revente du produit.

Le cloisonnement est posé dans la base de données, pas dans le code applicatif. AiO est destiné à être déployé chez plusieurs organisations : le cloisonnement n'est donc pas une précaution, c'est le produit lui-même. Chaque ligne porte son organisation propriétaire, et une règle de sécurité au niveau du moteur filtre systématiquement. Même si le code applicatif comportait un défaut, la base ne rendrait pas les lignes d'une autre organisation.

C'est ce qui rend le déploiement multi-clients défendable devant un tiers — un partenaire, un auditeur, ou l'organisation elle-même.

Infrastructure & déploiement

Le logiciel est conteneurisé, donc indifférent à son hébergement : serveur local, cloud privé, cloud public ou hybride. C'est une décision qui vous appartient et qui se prend au cadrage, parce qu'elle engage le coût et la résidence des données.

Intégrations & écosystème

Six partenaires de transfert, les banques, le Mobile Money, les services annexes — tous atteints par un module unique paramétré, non par six développements distincts. Les niveaux d'alimentation et les conditions d'accès sont détaillés sur la page Intégration partenaires.

Pilotage & gouvernance

Tableaux de bord exécutifs, alertes, rapports et statistiques ne sont pas une couche à part : ce sont des lectures du grand livre et des opérations. Ils n'ont pas de vérité propre, et c'est précisément ce qui garantit qu'ils ne peuvent pas diverger du réel.

Ce que cela vous donne le jour d'un contrôle

Un régulateur, une banque partenaire ou un auditeur ne demande jamais « montrez-moi votre logiciel ». Il demande une reconstitution : cette journée-là, cette opération-là, ce client-là. Qui a fait quoi, quand, sur quelle machine, validé par qui, et selon quelle règle en vigueur à ce moment-là.

C'est précisément ce que ce système d'information rend possible — et ce qu'aucun tableur, ni aucune base où l'on modifie les lignes, ne pourra jamais produire.