Dans un environnement désertique, les ressources sont tellement rares qu’il est impératif d’exploiter chaque goute d’humidité, chaque brise du matin, chaque particule organique pour survivre.

L’Afrique, est pour les entrepreneurs IT, ce que le désert est pour les plantes. Les ressources sont tellement rares, qu’il est impératif d’exploiter l’ensemble des ressources techniques, humaines et financières qui se présentent à eux. Mais la vie est possible, voir même magnifiquement possible, à condition de passer maître dans l’art de rationaliser.

Au moment où en occident, des gamins munis de powerpoint obtiennent des financements sur idées de produit de niche, des intégrateurs, des éditeurs et des passionnés africains avec de vrais projets et de vraies idées innovantes doivent survivre avec le peu de ressources qui se présentent à eux.

Pour prospérer, notre écosystème doit adopter sa propre voix, ne s’inspirer que de son environnement et exploiter ces contraintes pour en faire des opportunités.

L’apport potentiel de l’Open Source dans cette optique est aujourd’hui incontestable : des briques technologiques robustes et éprouvées disponibles en abondance et couvrant quasiment l’ensemble des besoins sociaux-économique du continent.

Malheureusement ce potentiel ne peut être transformé en réalité que par un écosystème conscient qui cessera de rêver les rêves des autres, ce qui manque vraiment en Afrique.

L’écosystème local n’aura de raison d’être que s’il apporte des solutions plus adaptées à notre environnement pour résoudre les problèmes de nos concitoyens en arrêtant de leur demander d’avoir les problèmes qu’ils n’ont pas le luxe d’avoir.

Si cet écosystème n’arrivent pas à se différencier des solutions internationales génériques, open-source ou pas, alors quel sera son rôle ? comment résister aux machines de guerre qui sont les géants internationaux, en plus du manque atroce de ressources ?

Voir dans les technologies open-source internationales disponibles une ressource comme une autre sur la voix du développement du continent est le début d’un long chemin dont dépend la prospérité de nos concitoyens.

Comme toute technologie importée d’ailleurs, conçue et réalisée sur la base de scénarii d’usage occidentaux, les technologies open-source doivent être revues et adaptées aux contextes et usages locaux. Mieux encore, leur feuille de route, doit s’aligner sur les évolutions locales. Or ce travail est colossal.

Pour les solutions propriétaires, le travail d’adaptation, de promotion et de lobbying est fait par des éditeurs puissants à travers un réseau de partenaires locaux qu’ils soutiennent par la formation et l’assistance. Ce qui est rarement le cas des communautés open-source.

Un autre paramètre, et pas des moindre, est que hormis quelques initiatives réellement libres, la majorité des initiatives open-source sont des techniques marketing comme les autres : commencer avec une version open-source uniquement, se faire connaître, pousser l’adoption par la gratuité des licences et même du support, commencer à vendre du service, la vente exclusive de service ne suffit plus, créer une version commerciale meilleure, ralentir d’innover sur la version gratuite, récupérer les clients de la version gratuite, est une séquence de comportement largement utilisée dans le domaine.

De ce fait, la disponibilité des solutions open-source “occidentales” ne doit pas être un motif de relâchement d’effort de la communauté technologique locale. l’Open Source nous permet de ne pas réinventer la roue, de rationaliser les ressources, mais un grand travail d’appropriation, d’adoption et de maîtrise stratégique doit être fait.

L’objectif final devra être de maîtriser la stratégie pour l’aligner sur nos besoins et de faire de nos contraintes locales, des opportunités.

Les africains, qui pensent soulager leur conscience, vis-à-vis de leur manque d’innovation et de vision, par l’adoption de l’open-source, qui remplace les solutions propriétaires, doivent prendre conscience que ça ne change en rien la situation : la dépendance vis-à-vis de la technologie occidentale.

Réduire cette dépendance et servir nos concitoyens avec des solutions adaptées à leurs contextes et inspirées de leurs problèmes ne pourra pas se faire en contribuant dans les communautés open-source d’origine pour les raisons suivantes :

• Comme tout produit logiciel, le développement des outils et solutions open-source est basé sur un cycle de vie complexe qui commence par la conception de la version initiale et par l’établissement d’une feuille de route de développement. La conception initiale et la feuille de route sont influencées par les hypothèses de travail et les scénarii d’utilisation retenus par les initiateurs.
• Les feuilles de route (Roadmaps) des produits open-source sont établies ou bien par des entreprises à l’origine ou bien par des communautés quasi-démocratiques influencées par les besoins de la majorité, de certains leaders techniques et des entités qui possèdent un grand poids dû à leur volume de contribution. Tout ce beau monde s’inspire de l’environnement et des problématiques purement occidentales, rarement une prise en compte de nos spécificités et de notre contexte économique, social et structurel.
• En étant de petits contributeurs individuels, les passionnés africains, n’auront pas pour l’instant le poids nécessaire pour influencer les feuilles de route (Roadmaps) des communautés existantes sauf s’ils démarrent leurs propres projets open-source.
• En cas de lancement de nouvelles initiatives, open-source ou pas, de zéro, la faible puissance actuelle des communautés et entreprises locales, ne permettra pas d’attirer un nombre suffisant de contributeurs ou une notoriété suffisante spécialement au regard de la faiblesse du financement local.

À la lumière des points précédents, il en ressort que ni la contribution aux initiatives internationales pour les influencer ni le lancement de nouvelles initiatives purement locales ne pourra être effective dans l’état actuel des choses. il n’y a pas de raccourcis possibles. Un grand travail progressif et bien planifié devra être mis en place, et en voici les étapes :

Première étape : l’adoption des solutions open-source internationales pour arrêter l’hémorragie.

La priorité absolue sera de réduire au maximum les transferts en devises vers l’étranger pour utiliser la majorité absolue des budgets IT locaux pour le développement de l’écosystème local.

Cette phase doit être basée sur l’appropriation et la maitrise commerciale des solutions open-source par les intégrateurs locaux. Elle permettra de réduire le coût d’acquisition des solutions informatiques par les clients locaux aux faibles moyens, de réduire les barrières à l’adoption des TIC et de garder la majorité du budget IT localement, dans le pays ou la région.

Cette étape ne pourra réussir que si les intégrateurs arrivent à positionner la valeur ajoutée reçue par le client et non pas la gratuité des licences ou l’ouverture du code source qui sont de faux débats pour les clients, spécialement les PME/PMI locales.

Aussi paradoxal que cela parait, le positionnement des solutions open-source sur la base exclusive de l’ouverture du code et la gratuité des licences, pratiques courantes aujourd’hui, ne sont vraiment attractives qu’aux yeux des grandes entreprises subissant les affres des modèles de licencing des grands éditeurs et qui possèdent les compétences informatiques nécessaires pour comprendre ce positionnement.

En effet, ne possédant pas les ressources humaines techniques nécessaires, Les PME/PMI locales jugent qu’ils ne profiteront pas de l’ouverture du code source et préfèrent en général confier leurs problématiques a un seul intégrateur / éditeur / freelance de confiance. leur seul soucis est le budget global et la couverture du besoin par la solution.

J’ai même eu affaire un jour à un gérant d’entreprise qui croyait que si le code source est ouvert alors n’importe qui pourra accéder et modifier les données. Allez lui expliquer l’inverse sans trop plonger dans le détail technique.

Le mot clef du message commercial doit être « Nous avons la solution à votre problème à moindre coût que la concurrence propriétaire et avec les mêmes garanties » et non pas « notre solution est en open source », « en Java », « elle fonctionne sous Linux »,…etc.

Ne pas mettre en avant le fait que la solution en question est open-source, ne veut pas dire mentir sur l’origine de la solution, mais adapter le langage à la cible. Il est clair qu’il faudra respecter les licences open-sources du produit utilisé et communiquer l’information à la population adéquate ou bien à celui qui pose la question.

Au final, quelque années de pratique et de maîtrise, procureront de l’assurance, de la maîtrise des problématiques fonctionnelles et sectorielles, de la maîtrise des technologies de base à l’écosystème local, tout en étant rentable et en réduisant les barrières à l’adoption de la technologie par le secteur économique local.

A la fin de cette phase, la majorité absolue du budget consacré aux TICs, servira le développement de l’écosystème local et le préparera aux prochaines phases.

Deuxième étape : Valeur ajoutée locale avec une forte maîtrise technique

Au fil des projets, les entreprises de services locales, pourront injecter de plus en plus de personnalisation et d’encrage local aux solutions de base.

Au départ, les adaptations seront de type ponctuel, au gré des besoins individuels du client. Avec le temps, les intégrateurs collecteront des actifs important en termes de développement de fonctionnalités réutilisables, de compléments, d’outils d’automatisation ou de migration, de documentation technique, ce qui représentera un véritable butin de guerre.

La gestion stratégique de ces actifs poussera, petit à petit, les intégrateurs à se comporter en éditeurs : Le besoin de pré-packager ses propres personnalisations, gérer les versions et la compatibilité entre version, améliorer le contenu technique et didactique, …etc; se fera de plus en plus ressentir.

La transformation progressive des prestataires de service vers fournisseurs de technologies augmentera leur niveau de maitrise de la feuille de route des solutions que ce soit en devenant des membres actifs des communautés d’origines ou bien en créant leurs propres communautés et écosystèmes selon les possibilités permises par les licences d’origine.

Certaines licences comme la MIT, sont permissive, c-à-d, elles permettent le fait de fusionner les adaptations avec le produit de base et d’en faire un nouveau produit sous une nouvelle licence voir même une licence fermée; d’autre licences open-source, comme les licences Apache, permettent le fork, c-à-d, de combiner les adaptations avec le produit de base sous un nouveau nom mais avec une propagation des termes de la licence de base, tout en ayant la maîtrise de le feuille de route du nouveau produit. Certaines licences open-source permettent de garder les personnalisations privées; d’autres sont dite contagieuses, c-à-d, que même si vous faite un complément externe il doit être lui même open-source et public.

Le bon choix des produits de base permettra à terme d’opter pour le lancement d’une nouvelle distribution, d’un fork ou d’un nouveau produit complètement différent.

Troisième étape : maîtrise stratégique totale

L’étape finale, permettra aux acteurs locaux d’avoir une maîtrise stratégique totale ou partielle des technologies ou des solutions en question.

Selon la valeur ajoutée dégagée lors de la phase précédente, de la licence d’origine et du comportement de la communauté initiale, plusieurs choix s’offrent aux communautés locales :

Packaging sous forme de distribution (distro)

Ce model était très utilisé dans le domaine des systèmes d’exploitation Linux et il revient à la mode dans les solutions Big data par exemple. Le packaging peut être fait en regroupant, homogénéisant et documentant plusieurs autres composants open-source comme le font “Hortonworks” dans le Big Data et “Ubuntu” dans les systèmes d’exploitation, ou bien en gardant une partie propriétaires comme leurs concurrents “Cloudera” et “ Red Hat”.

En général, la communauté, ou l’entreprise, derrière une distribution possède une très bonne maîtrise sur la stratégie, spécialement la feuille de route, même si elle reste largement tributaire des communautés d’origine “kernel linux” et “Hadoop” dans le cas des exemples cités précédemment.

Le fork ou la branche.

Une branche “fork” est une variante complètement autonome de la solution d’origine.

La pratique du fork est très répondue spécialement lors de la divergence de vision entre des parties prenantes activant au sein de la même communauté.

Au moment de la séparation entre les branches, les ressemblances sont larges et la valeur ajoutée du nouveau fork est à peine perceptible. Il est même possible de migrer facilement des fonctionnalités ou du code entre les deux branches au départ. Avec le temps et l’évolution des deux branches, la branche locale sera complètement autonome au point où elle ne sera plus compatible avec la branche internationale. La communauté locale lui donnera la direction la plus adaptée aux besoins locaux.

Utilisation des technologies open source dans des solutions propriétaires.

Devant la fermeture de certains secteurs comme les télécommunications et le secteur financier aux solutions open source, certains acteurs seront tentés par cette approche. Spécialement que cette pratique, répondue en Chine, en Inde et en Russie a vraiment apporté des réussites commerciales. Juste à titre d’exemple, des solutions logiciels open source packagées par un équipementier télécom chinois, sont actuellement en exploitation en Algérie chez un grand acteur mobile moyennant un payement de redevance colossale. Cet même outil, commercialisé dans toute l’Afrique et dans les pays pauvres, a permis à cet équipementier chinois de prendre des parts de marché significatives à ses rivaux occidentaux vu le prix relativement bas par rapport à leur solution propriétaire. Les exemples ne manquent pas dans ce sens.

Le hic, est que cette pratique n’est viable que dans le cas du non respect des licences d’origines.

En effet, ils sont vraiment rares les outils et solutions open-source intéressantes qui sont développées sous licences permissives, donc qui permettent l’appropriation complète par l’entreprise locale.

Il reste que beaucoup de SDK et de framework dans beaucoup de domaines sont sous licence permissive : reconnaissance de caractère, analyse de données, visualisation des données, …etc.

L’utilisation de SDK et de framework de ce type raccourcie le cycle de développement mais ne permet pas de réduire les besoins de financement pour développer des solutions commercialement viables rapidement.

Les pratiques chinoises et russes en termes de détournement des licences open-source, se déroulent en générale ainsi :

• Utilisation dans le marché local des solutions open source sans avoir à se justifier. Les solutions sont rodées, maîtrisées et adaptées au contexte local en exploitant le potentiel du marché domestique.
• La puissance industrielle des entreprises chinoises leur permettent de s’introduire en premier sur les marchés des pays sous-développés très peu regardant sur les aspects de propriété intellectuelle.
• Ensuite, après plusieurs années de facturation de licences de solutions open source détournées et légèrement maquillées, le gros butin de guerre amassé leur permet de noyer la solution initiale dans une vrais propriété intellectuelle propre et s’attaquer aux marchés occidentaux.

Au Delà des aspects relatifs à l’intégrité, cette démarche ne sera pas porteuse pour les entreprises africaines, qui ne possèdent pas un marché local aussi important et qui ne possèdent pas la facilité de l’internationalisation des entreprises chinoises ni la puissance de l’état qui protège son écosystème local contre la menace juridique.

Heureusement que l’avènement du Cloud réduit significativement cette contrainte. Dorénavant tout ce qui compte pour le client est que la solution répond à ses besoins et qu’elle soit accessible. la technologie utilisée ne sera plus un grand sujet et les secteurs habituellement réticents à l’open-source n’auront plus le choix. ils devront passer un jour ou l’autre au Cloud, monde ou l’open-source règne en maître.

Au final, quelque soit la forme retenue, Distro, Fork, ou Cloud, la maîtrise stratégique sera entière et permettra une évolution alignée sur les besoins de l’Afrique portée par des acteurs économiques qui ont su raccourcir le cycle de développement au maximum sans compromettre ni leur indépendance stratégique ni leur pérennité économique.

Abdelmalek Chetta