ZLECAf : votre ERP est-il prêt ?

Ouvrir une filiale à Dakar ou à Nairobi prend quelques mois. Y faire suivre la comptabilité, les stocks, la paie et les données clients prend souvent bien plus longtemps. Pour Sidney N'ZI, c'est là que se joue la réussite d'une expansion.

Sidney N'ZI est passé par les départements IT de la holding Afrique d'Allianz et d'AGL. Il est aujourd'hui manager transformation digitale chez TechWise Solutions, une entreprise de services numériques, et chef de projet IT senior dans un groupe financier présent sur le continent.

« Des systèmes conçus pour des frontières nationales »

Avec la ZLECAf, de plus en plus d'entreprises s'étendent dans plusieurs pays africains. Leur système d'information suit-il le rythme ?

Beaucoup d'entreprises sur notre continent se développent aujourd'hui beaucoup plus vite que leurs systèmes d'information. Elles opèrent dans plusieurs pays, mais continuent souvent à gérer leurs données, processus et outils en silos : chaque filiale à son niveau, de manière indépendante, avec des outils variés. Or la ZLECAf implique de l'interopérabilité, de la standardisation et une vision consolidée à l'échelle continentale. Concrètement, on ne bâtira pas un marché continental avec des systèmes conçus pour des frontières nationales.

Ni tout centraliser, ni tout dupliquer

Un ERP unique pour tout le groupe, ou un ERP par pays ? La réponse dépasse ce choix binaire.

Quand un groupe opère dans plusieurs pays, comment organise-t-il son ERP ?

Il n'existe pas de modèle unique d'un groupe à un autre. Néanmoins, la plupart des groupes panafricains adoptent aujourd'hui une approche hybride : un ERP groupe unique, un référentiel de données partagé, des processus opérationnels standardisés, et quelques adaptations locales lorsque la réglementation l'exige. Par expérience, le meilleur ERP n'est pas celui qui uniformise tout, mais celui qui standardise ce qui crée de la valeur et localise ce que les autorités réglementaires imposent.

« Le meilleur ERP n'est pas celui qui uniformise tout, mais celui qui standardise ce qui crée de la valeur et localise ce que les autorités réglementaires imposent. »

Quand les États veulent garder les données chez eux

Le business veut un système unifié, les États veulent garder les données sur leur sol. Comment les entreprises gèrent-elles cette tension ?

C'est l'un des grands enjeux de la transformation digitale en Afrique. En Afrique de l'Ouest et du Centre en particulier, les entreprises y répondent généralement grâce à des architectures distribuées. Par exemple, chaque filiale conserve sa base de données clients et ses données personnelles dans son pays, pour respecter les exigences de souveraineté. En revanche, les données nécessaires au pilotage du groupe, comme les indicateurs financiers, commerciaux ou opérationnels, sont synchronisées vers une plateforme centrale via des API ou des mécanismes d'intégration sécurisés. L'ERP n'est alors plus forcément centralisé : c'est l'information qui est fédérée. Le défi consiste à garantir une vue unique de l'entreprise sans déplacer inutilement les données sensibles.

C'est le cœur de l'affaire. Longtemps, on a cru devoir choisir entre l'unité du groupe et le respect des lois locales. L'information fédérée tranche ce faux dilemme : la souveraineté des données devient une question d'architecture, pas un frein à l'expansion.

La conformité, dès le premier jour

Les lois sur la protection des données se multiplient sur le continent. Les avez-vous vues changer des architectures en cours de projet ?

Cela se produit quelquefois, et c'est précisément pour cette raison que la conformité ne devrait jamais arriver en fin de projet. Lorsque des contraintes de localisation, de transfert ou de protection des données apparaissent tardivement, elles peuvent remettre en cause l'hébergement, les interfaces ou certains flux. Pour un chef de projet, le risque est important : une architecture techniquement excellente peut devenir obsolète si elle n'est pas conforme dans les pays concernés. Dans un projet multi-pays, les contraintes réglementaires doivent donc être identifiées dès le cadrage.

Pour l'utilisateur, une seule question : est-ce que ça marche ?

Concrètement, qu'est-ce que ça change pour un utilisateur à Lagos ou Nairobi, selon l'endroit où tourne l'ERP ?

Pour l'utilisateur, tout se joue sur le temps de réponse, la disponibilité et la continuité de service. Plus l'infrastructure est éloignée ou dépendante de connexions internationales, plus la qualité du réseau peut influencer ces temps de réponse et la disponibilité. Selon le pays et la nature des données traitées, le choix d'hébergement peut également avoir des implications en matière de conformité, d'accès aux données et de continuité d'activité. Mais un utilisateur à Lagos ou Nairobi ne devrait pas avoir à se préoccuper de l'architecture retenue. Le bon choix est justement celui qui rend ces contraintes invisibles pour lui, tout en restant conforme et résilient.

Une décision de direction, pas seulement d'informaticiens

Le choix de l'hébergement, c'est une décision technique ou une décision de direction ?

J'estime que c'est une décision de direction éclairée par la technique. L'IT doit objectiver les différents scénarios : performance, sécurité, disponibilité, coûts, réversibilité, conformité, localisation des données et continuité d'activité. Mais le choix final engage l'entreprise sur des risques opérationnels, réglementaires et stratégiques. Le rôle de l'IT est de rendre les arbitrages lisibles pour la direction. La technique détermine ce qui est possible, mais c'est la gouvernance qui décide des risques acceptables.

« La technique détermine ce qui est possible, mais c'est la gouvernance qui décide des risques acceptables. »

Que se passe-t-il quand cet arbitrage est repoussé ?

Repousser cette décision ne supprime pas le risque. Cela signifie simplement que l'on accepte que les circonstances décident plus tard à notre place. Le problème peut apparaître au moment d'un audit, d'une évolution réglementaire, d'une panne d'infrastructure ou de l'ouverture d'une filiale dans un nouveau pays. L'entreprise agit alors dans l'urgence plutôt que dans une logique d'architecture maîtrisée. Beaucoup repoussent ces arbitrages au nom de « l'agilité ». Pourtant, certaines décisions coûtent peu lorsqu'elles sont prises en amont, et deviennent extrêmement complexes à corriger après le déploiement.

L'avertissement vaut pour toutes les tailles d'entreprise. L'agilité permet d'ajuster un produit en cours de route ; elle ne permet pas de déplacer des données hébergées dans le mauvais pays sans en payer le prix.

Avant de passer la frontière

Une PME qui ouvre son deuxième pays n'a pas les moyens d'un grand groupe. Sidney N'ZI lui conseille de ne pas le copier, mais d'en retenir les principes : standardiser ses données et ses processus essentiels, et choisir des outils capables d'évoluer avec elle, en intégrant les contraintes du deuxième pays avant le déploiement. Et à tout dirigeant qui prépare son expansion, il propose trois questions à poser sur son ERP :

1. Mon ERP peut-il absorber les règles du nouveau pays sans remettre en cause mon modèle actuel ? Fiscalité, réglementation, devise, langue, reporting et processus locaux.
2. Où seront mes données, et ai-je légalement et opérationnellement le droit de les exploiter ainsi ? C'est une question de conformité, mais aussi de maîtrise du risque.
3. Que se passe-t-il si la connexion, le cloud ou le système central devient indisponible ? Cette question oblige à regarder la résilience réelle de l'architecture.

« Avant de franchir une frontière commercialement, une entreprise devrait vérifier que son système d'information est lui aussi capable de la franchir ; c'est malheureusement l'inverse qui se produit en règle générale. »

Building Africa donne la parole à celles et ceux qui construisent le numérique du continent. Abonnez-vous à la page LinkedIn Building Africa pour ne rien rater.