Il y a près de 10 ans maintenant, je faisais mon mémoire de maîtrise et celui-ci était publié au CIRANO (Centre Universitaire en Analyse des Organisations) sous forme d’un Rapport Bourgogne LES WEB SERVICES ET LEUR IMPACT SUR LE COMMERCE B2B [2] (PDF), puis j’étais invité au Council on e-business innovation du Conference Board of Canada pour le présenter.
Pour rendre une histoire longue et compliquée accessible à tous, je vous dirai ceci. Les fuck-up TI sont peut-être associés sans doute à du graissage de patte éhonté, mais aussi à une approche d’intégration qui rend les projets impossible à livrer et créent une spirale inflationniste ingérable. Voici donc l’explication.
Supposons que vous vouliez relier entre elle cinq applications d’affaires différentes. Dans un processus d’intégration classique, vous avez besoin du carré du nombre de connexions, en termes de branchement à la nouvelle application commune que vous créerez. Les employés de chacun des départements devront suivre de nombreuses formations pour comprendre comment le nouveau système créé fonctionne. Aussi, si l’une de ses applications change, vous devrez refaire chacune des connexions à cette application et modifiez la majeure partie de votre système et recommencez la formation (qui inclut, il va de soi ce qu’on appelle aussi la gestion du changement). Comme l’univers organisationnel est de facto un univers en changement permanent, la spirale des coûts et des recommencements successifs explose assez rapidement. Dans une approche Web Services, on se fou des applications et on ne touche pas du tout à son intégrité. Tout ce qu’on fait est de se questionner sur les informations ou les processus d’affaires qui ont une valeur à être partagé et grâce à une série de standards permettant l’interopérabilité universelle, on ne développe que des connexions qui ne touchent pas à l’intégrité des applications. En quelques mois et à faibles coûts, on a déjà des applications diverses qui se parlent, les employés n’ont pas besoin d’apprendre de nouvelles applications et une fois un certain nombre d’informations ou de processus d’affaires partagé par tous et évalué en terme de bénéfices directs, on décide quels autres informations ou processus valent la peine d’être intégré. Voilà.
Il y a plusieurs années je mangeais avec un gros VP d’une firme d’intégration à trois lettres et je lui demandais
Mais pourquoi ne faites-vous pas de Web Services aux différentes instances gouvernementales? Vous connaissez les standards, vous savez qu’ils fonctionnent alors pourquoi ne sont-ils pas utilisés?
Il me répondit
Nous sommes en affaire pour faire du fric, pas de l’éducation. Le gouvernement veut de l’intégration, on lui en vend.
Je vous rappelle qu’on a le scandale du Registre Canadien des armes à feu [3], celui d’inforoute santé Canada [4], celui de GIRES [5] qui après 500 millions a changé de nom pour devenir SAGIR [6], celui de dernier rapport du vérificateur général du Québec et relaté dans l’article de Direction Informatique Dossier de santé du Québec : « un échec », conclut le Vérificateur général [7] de même que de nombreux autres scandales de plusieurs centaines de millions de dollars ou même de milliards, et qui ne fonctionnent toujours pas.
On parle de scandale de la construction. Cependant en supposant qu’il y ait malversations dans cette industrie, au moins sur un projet d’autoroute qui coûte 500 millions et dont des entrepreneurs se graissent largement la patte, au bout il y a tout de même une autoroute. En TI, au bout il n’y a strictement rien. Ou plutôt si, il y a de nombreux rapports…
Je vous rappelle aussi que les appels d’offres du gouvernement excluent de facto, les petites organisations de TI qui ont l’habitude de développer des applications et de l’intégration pour des multinationales reconnues mondialement (notamment avec des Web Services ou en développement avec la méthode agile [8]) mais qu’ils ne peuvent jamais travailler pour nos gouvernements parce qu’ils n’ont pas des chiffres d’affaires de plusieurs centaines de millions de dollars, parce qu’ils ne sont pas ISO ou tout simplement parce qu’ils ne font pas parti de la clique très fermée du « Boys club » des décisionnels des TI gouvernementaux.
Voici maintenant un extrait de l’explication plus scientifique [2](PDF) :
Une autre problématique à laquelle font face les entreprises se tournant vers Internet est le nombre croissant de partenaires potentiels. Cette croissance est souvent liée à une augmentation des coûts liés à l’élaboration et le déploiement des interfaces entre les systèmes d’information de ces partenaires. En particulier, trois défis se posent :
• Distribution des centres de contrôles : Les entreprises peuvent dicter l’utilisation d’une plate-forme homogène à l’intérieur de leurs frontières. Ils peuvent même obliger certains de leurs fournisseurs à s’adapter à cette plateforme s’ils ont une position dominante déterminante. Cependant, lorsque le nombre et la diversité des partenaires augmentent, il devient difficile de maintenir un seul centre de contrôle;
• Diversité des plates-formes technologiques : Sans un centre de contrôle unique, les entreprises se battent continuellement avec la diversité croissante des plates-formes qu’ils ont à brancher. Ces branchements se doivent aussi d’être abordables et réalisables pour les PME qui doivent aussi supporter les coûts de ses branchements;
• L’environnement dynamique : Dans un monde économique en mouvance perpétuelle, les entreprises se doivent d’être capable d’intégrer les nouveaux partenaires à leurs systèmes informatiques et ce, de façon efficace, rapide et économique. Ils doivent aussi avoir la flexibilité d’abandonner certaines alliances d’affaires sans avoir à radier de leurs bilans des dépenses et investissements technologiques.
En réponse à ces défis, les Web Services offrent les solutions suivantes :
• La simplicité : Les Web Services réduisent la complexité des branchements tout en rendant la tâche plus facile aux nouveaux participants. Cela se fait en ne créant la fonctionnalité qu’une seule fois plutôt qu’en obligeants tous les participants à reproduire la fonctionnalité à chacun des bouts (comme avec l’architecture client/serveur);
• Composante logicielle légèrement couplée : L’architecture modulaire des Web Services, combinée au faible couplage des interfaces associées, permet l’utilisation et la réutilisation de services qui peuvent facilement être recombinées à différents autres modules;
• Hétérogénéité : Les Web Services permettent d’ignorer l’hétérogénéité entre les différentes applications et modules. En effet, ils décrivent comment transmettre un message (standardisé) entre deux applications, sans imposant comment construire ce message;
• Ouverture : Les Web Services permettent de réduire les inquiétudes liées aux différents «lock-in» que les entreprises subissent des fournisseurs informatiques. Ils permettent aussi de tirer une valeur économique supplémentaire des infrastructures informatiques existantes et des plates formes ouvertes tel que l’Internet