People who operate
deserve better tools.

Les entreprises qui opèrent en offshore ou sur bases vie gèrent une contrainte que
peu de logiciels comprennent : le suivi des effectifs présents, l'autonomie des
stocks en ravitaillement irrégulier, et la traçabilité HSE exigée par les majors.
Trois sujets critiques, souvent tenus à la main.

### Le problème : Excel, papier et téléphone en zone isolée

Sur une base vie ou un site offshore, le suivi du **POB** (Personnel On Board,
l'effectif présent à un instant donné) et des **PAX** (personnes hébergées ou
transportées, suivies nominativement) se fait encore trop souvent sur un tableur
partagé, un cahier, ou par téléphone au superviseur. Même chose pour les stocks
alimentaires et la traçabilité **HSE**. Le résultat est prévisible : ravitaillement
mal anticipé, incidents mal documentés, effectifs impossibles à consolider en
temps réel pour la direction ou pour un audit d'un donneur d'ordre.

La cause profonde n'est pas le manque de sérieux des équipes — c'est que l'outil
suppose un réseau qui, sur site, ne suit jamais tout le temps.

### Ce que change une plateforme conçue pour le terrain

Trois briques concrètes suffisent à reprendre le contrôle :

- **Gestion POB/PAX** : suivi des effectifs présents, rotations d'équipes,
historique de présence par site. Qui est à bord, depuis quand, jusqu'à quand —
consolidé, pas reconstitué à la fin du mois.
- **QHSE natif** : incidents, audits, traçabilité HSE horodatée. La preuve
demandée par les majors et leurs partenaires existe parce qu'elle a été saisie
au moment de l'événement, pas reconstruite après.
- **Autonomie alimentaire & stocks (HACCP)** : anticipation du ravitaillement et
gestion des stocks alimentaires selon la méthode HACCP, pour ne pas découvrir un
manque quand le prochain supply vessel est encore à trois jours.

### L'argument technique qui fait la différence : offline-first

L'application ANAGA (Android et iOS) continue de fonctionner **sans connexion**.
Les équipes pointent, scannent, valident sur site ; la synchronisation se fait
automatiquement dès qu'une connexion redevient disponible, avec résolution des
conflits côté serveur. Aucun écran bloquant pour les équipes terrain. C'est de
l'offline-**first**, pas de l'offline-fallback : le mode hors réseau est le mode
normal, pas une rustine.

À cela s'ajoutent une **instance dédiée par client** (données isolées, pas de
mutualisation), une **comptabilité OHADA native** pour la consolidation multi-sites,
et des contrats en **XAF** — pas de risque de change.

### Pour qui, concrètement

Pour les opérateurs et sous-traitants du pétrolier et du parapétrolier, les
sociétés de bases vie, de catering et de logistique offshore, qui doivent rendre
des comptes en HSE tout en gérant une contrainte de connectivité permanente.

ANAGA Offshore a été conçu par Essaka Engineering avec les contraintes réelles des
opérations offshore et des bases vie au Gabon. Si vous opérez dans ce contexte,
une présentation de 20 à 30 minutes suffit pour voir si la plateforme correspond à
votre réalité terrain. **[Demander un audit gratuit →]**

---

— Publié depuis l'ERP ANAGA

Les entreprises qui opèrent en offshore ou sur bases vie gèrent une contrainte que peu de logiciels comprennent : le suivi des effectifs présents, l'autonomie des stocks en ravitaillement irrégulier, et la traçabilité HSE exigée par les majors.

Le problème : Excel, papier et téléphone en zone isolée

Le suivi du POB (Personnel On Board, l'effectif présent) et des PAX (personnes hébergées, suivies nominativement) se fait encore trop souvent sur un tableur, un cahier ou par téléphone. Résultat : ravitaillement mal anticipé, incidents mal documentés, effectifs impossibles à consolider en temps réel. La cause profonde ? L'outil suppose un réseau qui, sur site, ne suit jamais tout le temps.

Ce que change une plateforme conçue pour le terrain

• Gestion POB/PAX : effectifs présents, rotations d'équipes, historique de présence par site.
• QHSE natif : incidents, audits, traçabilité HSE horodatée — la preuve existe parce qu'elle a été saisie au moment de l'événement.
• Autonomie alimentaire & stocks (HACCP) : anticipation du ravitaillement selon la méthode HACCP.

L'argument technique : offline-first

L'application ANAGA (Android et iOS) continue de fonctionner sans connexion. Les équipes pointent, scannent, valident sur site ; la synchronisation se fait automatiquement au retour du réseau, avec résolution des conflits côté serveur. C'est de l'offline-first, pas de l'offline-fallback. S'y ajoutent une instance dédiée par client, une comptabilité OHADA native et des contrats en XAF.

Pour qui

Pour les opérateurs et sous-traitants du pétrolier et du parapétrolier, les sociétés de bases vie, de catering et de logistique offshore. ANAGA Offshore a été conçu par Essaka Engineering avec les contraintes réelles des opérations offshore au Gabon. Une présentation de 20 à 30 minutes suffit pour voir si la plateforme correspond à votre réalité terrain.

« Il faut qu'on se digitalise. » La phrase est facile à dire en réunion. Sur le
terrain, elle se heurte à une réalité : les équipes sont sur des chantiers, des
sites, des bases — pas devant un écran de bureau. Digitaliser une PME de terrain
ne se fait pas comme on installe un logiciel de comptabilité au siège. Voici une
méthode en quatre étapes, pensée pour ceux qui opèrent, pas seulement pour ceux
qui pilotent.

### 1. Partir d'une douleur précise, pas d'un outil

L'erreur la plus commune : choisir un logiciel avant d'avoir nommé le problème.
Commencez par la question inverse. Où perdez-vous concrètement du temps, de
l'argent ou de la traçabilité ? Un bon de commande validé sur un carnet et jamais
ressaisi ? Un stock découvert vide en fin de mois ? Une facture fournisseur qui
traîne trois semaines avant d'être rapprochée ? Notez la douleur avec les mots du
métier, pas avec le jargon informatique. C'est elle qui guide le reste.

### 2. Digitaliser le point de saisie, là où la donnée naît

La donnée se perd rarement dans le logiciel : elle se perd **avant**, entre le
terrain et le bureau. Le carnet qui reste dans la poche, le SMS qui n'est jamais
reporté, le bon signé sur papier. Le vrai gain vient quand la saisie se fait
**là où l'action a lieu** : l'opérateur qui pointe, scanne, valide depuis une
tablette ou un téléphone. Encore faut-il que l'outil fonctionne même quand le
réseau ne suit pas — sur un chantier isolé ou une base, il ne suit jamais tout le
temps. C'est le principe de l'offline-first : l'application continue de
fonctionner sans connexion et synchronise automatiquement au retour du réseau.

### 3. Un socle, puis des modules — pas un package figé

Digitaliser tout, tout de suite, est le meilleur moyen de tout abandonner. Mieux
vaut un socle commun (les clients, les documents, les utilisateurs) puis des
modules ajoutés au rythme des priorités : Stocks d'abord si c'est là que ça fait
mal, puis Achats, puis Finance. Cette modularité évite de payer — et de subir —
quatorze fonctions dont vous n'utiliserez que trois cette année.

### 4. Ancrer la conformité dès le départ

Une PME africaine n'a pas les mêmes contraintes qu'une multinationale. La
comptabilité doit être **OHADA**, les contrats en **XAF** pour éviter le risque de
change, l'hébergement des données doit être maîtrisé. Ces exigences ne se
rajoutent pas « après coup » : elles se choisissent dès le premier outil. Un ERP
pensé pour l'Afrique centrale les porte nativement ; un ERP généraliste mondial
vous demandera de les bricoler.

### En résumé

Digitaliser une PME de terrain, c'est : **une douleur nommée → un point de saisie
rapproché du terrain → un socle modulaire → une conformité locale native.** Dans
cet ordre. Le reste — dashboards, IA, consolidation — vient ensuite, quand les
équipes ont adopté l'outil parce qu'il leur simplifie la journée.

C'est exactement la logique qui a guidé la conception d'ANAGA, la plateforme des
gens qui opèrent, conçue par Essaka Engineering à Port-Gentil et Libreville.
Vous voulez savoir par quel module commencer dans votre cas ?
**[Demandez un échange →]**

---

— Publié depuis l'ERP ANAGA

« Il faut qu'on se digitalise. » La phrase est facile à dire en réunion. Sur le terrain, elle se heurte à une réalité : les équipes sont sur des chantiers, des sites, des bases — pas devant un écran de bureau. Voici une méthode en quatre étapes, pensée pour ceux qui opèrent, pas seulement pour ceux qui pilotent.

1. Partir d'une douleur précise, pas d'un outil

L'erreur la plus commune : choisir un logiciel avant d'avoir nommé le problème. Où perdez-vous concrètement du temps, de l'argent ou de la traçabilité ? Un bon de commande jamais ressaisi ? Un stock découvert vide en fin de mois ? Notez la douleur avec les mots du métier, pas avec le jargon informatique.

2. Digitaliser le point de saisie, là où la donnée naît

La donnée se perd rarement dans le logiciel : elle se perd avant, entre le terrain et le bureau. Le vrai gain vient quand la saisie se fait là où l'action a lieu : l'opérateur qui pointe, scanne, valide depuis une tablette ou un téléphone. Encore faut-il que l'outil fonctionne même quand le réseau ne suit pas — c'est le principe de l'offline-first.

3. Un socle, puis des modules — pas un package figé

Digitaliser tout, tout de suite, est le meilleur moyen de tout abandonner. Mieux vaut un socle commun (les clients, les documents, les utilisateurs) puis des modules ajoutés au rythme des priorités.

4. Ancrer la conformité dès le départ

La comptabilité doit être OHADA, les contrats en XAF pour éviter le risque de change, l'hébergement des données maîtrisé. Ces exigences se choisissent dès le premier outil.

En résumé

Une douleur nommée → un point de saisie rapproché du terrain → un socle modulaire → une conformité locale native. C'est la logique qui a guidé la conception d'ANAGA, la plateforme des gens qui opèrent, conçue par Essaka Engineering à Port-Gentil et Libreville.

Bonjour la communaute 👋

Ceci est notre tout premier message, publie automatiquement depuis ANAGA.