Dans les grandes organisations, certains choix technologiques semblent presque impossibles à remettre en question. SAP, Oracle, Salesforce ou d’autres grands progiciels occupent une place privilégiée dans les processus de sélection. Leur taille, leur notoriété et leur présence sur le marché constituent un argument puissant pour les décideurs. C’est compréhensible.

Lorsqu’un projet représente plusieurs millions de dollars et touche des processus critiques, choisir un acteur reconnu réduit le risque politique de la décision. Personne ne s’étonnera d’avoir retenu le leader du marché. Mais cela ne signifie pas nécessairement que la décision réduit le risque opérationnel.

Le problème n’est pas la taille du logiciel. C’est la concentration.

Un grand progiciel apporte une cohérence intéressante : un fournisseur, une architecture, un contrat, une responsabilité. Mais cette cohérence a un prix. Plus le périmètre fonctionnel s’élargit, plus l’organisation devient dépendante de la plateforme, de son modèle de données, de ses cycles d’évolution et de son écosystème de consultants.

Le logiciel finit alors par devenir une infrastructure autour de laquelle l’entreprise doit organiser ses processus plutôt que l’inverse, en plus de générer des coûts prohibitifs, notamment pour l’intégration, la personnalisation, la formation, la migration, les consultants, les mises à niveau et, surtout, le coût de chaque changement.

Une organisation peut ainsi se retrouver avec un système extrêmement sophistiqué… mais étonnamment difficile à faire évoluer.

À l’opposé du progiciel monolithique, un modèle distribué pourrait s’avérer un choix judicieux. Des solutions spécialisées, développées et maintenues par différents fournisseurs, communiquent au moyen d’API et de standards communs. Chaque composante fait relativement peu de choses, mais les fait bien. La valeur de ce modèle réside dans l’architecture de l’écosystème qui permet à plusieurs solutions de couvrir, ensemble, la totalité du besoin.

Un environnement composé de plusieurs produits n’est pas nécessairement fragmenté. Il peut être beaucoup plus cohérent qu’un immense progiciel, à condition que l’architecture, les données et les interfaces soient maîtrisées par le client.

Plusieurs fournisseurs, un seul écosystème

Cette approche change également la nature du risque. Lorsque tout un environnement repose sur un fournisseur unique, son évolution dépend essentiellement de lui. Dans un environnement distribué, une composante peut évoluer indépendamment des autres. Un fournisseur peut être remplacé, une nouvelle technologie peut être introduite progressivement, une innovation peut être testée sans remettre en question l’ensemble du système. Le risque est donc réparti.

La concurrence entre fournisseurs devient un mécanisme permanent d’amélioration. C’est particulièrement intéressant pour les entreprises qui veulent conserver leur capacité d’adaptation à long terme.

Le véritable défi : l’orchestration

Évidemment, cette architecture demande davantage de discipline. Il faut définir les responsabilités de chaque système, gérer les interfaces, assurer la cohérence des données, maintenir une stratégie de sécurité et disposer d’une vision d’ensemble. Bien que cela peut représenter un fardeau à implémenter et à maintenir, cette capacité devient rapidement une compétence stratégique.

L’entreprise conserve la maîtrise de son architecture au lieu de déléguer cette maîtrise à un fournisseur. Elle construit et gouverne un écosystème technologique.

Plusieurs de nos projets chez CODE 201 s’inscrivent dans ce cadre technologique. Que cela soit pour ajouter une composante complémentaire à un processus existant ou pour synchroniser les données entre les systèmes, nos solutions sont intégrées le plus possible à l’écosystème du client et gérées en continu.

Relation avec les fournisseurs

Les petits fournisseurs spécialisés doivent constamment démontrer leur valeur. Cela favorise des organisations plus agiles, plus proches de leurs clients et capables de répondre rapidement aux besoins particuliers d’un secteur.

Et lorsque ces fournisseurs sont locaux, une partie importante de la valeur créée par les investissements technologiques demeure dans l’économie régionale. On développe les compétences, on crée des emplois spécialisés, on fait émerger de nouveaux joueurs et, surtout, on construit un écosystème plutôt qu’une dépendance.

En revanche, ces fournisseurs doivent être prêts à intégrer davantage leurs produits et à permettre des personnalisations, notamment aux interfaces, pour permettre une expérience utilisateur unifiée dans l’écosystème du client. C’est une des raisons qui nous pousse à offrir, chez CODE 201, des interfaces personnalisables avec tous nos produits SaaS.

Les capacités à évoluer, à intégrer de nouvelles technologies, à remplacer une composante, à changer de fournisseur, à répondre rapidement aux besoins du terrain et à contrôler les coûts dans le temps sont des éléments à considérer avant de choisir de remplacer tous les systèmes internes par un grand progiciel intégré. (Certains exemples dans l’actualité récente me viennent en tête…)

Gérez vos écosystèmes au lieu de donner les clés à un vendeur de logiciels, vous aurez une meilleure architecture pour faire évoluer votre écosystème technologique.