Les 5 étapes d’Acheron pour réussir l’intégration d’OpenText et CHILI publisher

L’intégration d’un logiciel à ce niveau requiert toutefois le savoir-faire d’un expert tant en matière de planification que d’intégration. Dans cet article, nous avons demandé à Nandhakumar Shanmugam et Raj kumaran Malli, deux développeurs d’applications de pointe chez Acheron de partager leurs meilleures pratiques pour aborder l’intégration API d’OpenText avec CHILI publisher.

L’évolution continue d’Acheron vers l’approche idéale

L’intégration d’outils de gestion des informations pour une entreprise doit satisfaire une large gamme de besoins. Dans certains cas, le premier objectif d’une bonne API est de faire en sorte de rendre la chose possible, et c’est exactement ce que fait OpenText.

Acheron planifie, développe et intègre des solutions de données variables basées sur OpenText depuis près de dix ans. Durant cette période, nous n’avons pas seulement créé un grand nombre de solutions, nous avons aussi assisté à l’évolution rapide des API utilisées comme des exigences de nos clients.

C’est pour suivre cette évolution que nous avons aussi fait évoluer notre approche de l’intégration et du déploiement. Et fort heureusement, nous avons constamment pris des notes ! Forts de cette expérience qui est la nôtre dans l’intégration de données, nous avons identifié plusieurs approches éprouvées pour garantir une intégration à grande échelle réussie sur presque tous les marchés, secteurs et systèmes.

Pour les projets de production graphique en entreprise, Acheron s’est régulièrement adressé à CHILI publisher. CHILI publisher est bien adapté aux besoins des entreprises, et grâce à ses API puissantes, nous pouvons l’intégrer à OpenText pour le compte de clients Fortune 100 issus de divers marchés et secteurs, comme le commerce de détail, la finance, l’automobile. Les développeurs savent que deux excellentes API valent mieux qu’une seule, mais avant même d’écrire une seule ligne de code, il convient de respecter plusieurs étapes clés pour assurer la réussite de l’intégration de la manière la plus efficace et la plus économique possible. Voyons quelles sont ces étapes !

Étapes clés pour la réussite d’une intégration API d’OpenText

1. La phase de découverte : comprendre les besoins des utilisateurs

Pour chaque projet, la première chose à faire est de parler au client afin de comprendre quels sont les problèmes ou difficultés à résoudre. Parallèlement, il est également essentiel de poser les questions suivantes, et d’y répondre :

• Dans quelle mesure est-il essentiel pour votre entreprise de résoudre le problème ?
• Quels résultats en attendez-vous ?
• Quel est le délai alloué pour que la solution soit déployée et opérationnelle ?

Toujours pendant la phase de découverte, une fois que nous avons la vision d’ensemble du projet, nous nous intéressons aux détails, par exemple :

• Quels attributs et informations doivent être récupérés des systèmes intégrés ?
• Comment les informations doivent-elles être affichées ?
• L’intégration doit-elle utiliser le système Single Sign On (SSO) d’authentification et d’autorisation pour l’accès aux ressources ou peut-elle utiliser un compte de service, etc. ?
• Quels sont les paramètres et les procédures de sécurité ?

Clairement, de nombreux points vont dépendre de la nature du projet, mais vous saisissez l’idée générale : la phase de découverte vise à vérifier que vous avez une vision claire du projet dans sa globalité et des résultats attendus.

Si vous travaillez sur une intégration de conceptions basées sur des contenus avec CHILI publisher, par exemple, nous détaillons précisément quels types de supports imprimés et digitaux le client veut automatiser et nous faisons le lien avec les fonctionnalités de CHILI publisher pour obtenir le résultat voulu. Nous clarifions également quels contenus et types de contenus doivent transiter par les API depuis OpenText vers CHILI publisher.

Dans le même temps, nous documentons précisément toutes ces informations et les communiquons au client pour validation. Une fois approuvé, ce document de spécifications des exigences logicielles ou SRS (Software Requirement Specification), servira de guide pour la conception de l’expérience utilisateur, et la configuration technique et architecturale du système.

Partant du SRS, l’étape suivante est la conception de l’expérience utilisateur, ou UX Design. Cette étape a toute sa place ici, car la conception de l’expérience utilisateur sert de base à la configuration technique et architecturale du système.

2. UX Design : garantir la réussite de l’expérience client

Avant de décider de concevoir de zéro une nouvelle expérience utilisateur pour un projet, aussi tentant que cela puisse être, nous commençons toujours par vérifier auprès du client si l’entreprise n’a pas déjà une expérience utilisateur en place. C’est important pour deux raisons :

• Si l’entreprise a déjà un certain type d’expérience utilisateur en place, il lui sera difficile de s’adapter à des conceptions différentes.
• Les entreprises suivent en effet souvent certaines exigences importantes en matière de thème ou d’image de marque dans leurs applications. Pour ne pas affaiblir la marque, nous devons également respecter ces exigences.

Que nous décidions de concevoir une expérience utilisateur entièrement nouvelle pour le client ou de nous inspirer d’une conception existante, l’étape suivante consiste toujours à organiser une rencontre avec l’entreprise pour clarifier ses attentes et travailler ensemble à l’élaboration d’une proposition.

Si nous travaillons à partir d’une expérience utilisateur déjà en place, nous vérifions alors s’il existe des points faibles qu’il faudra traiter pendant le projet. C’est un petit plus généralement très apprécié lorsque nous décidons d’utiliser une expérience utilisateur existante.

Une fois que nous disposons de toutes les informations nécessaires, nous créons un prototype cliquable/fonctionnel et le présentons au client pour qu’il puisse le tester et voir comment les fonctionnalités et le système proposés fonctionnent. Cette approche proactive a l’avantage d’éviter tout malentendu, dans la mesure où le client sait exactement à quoi s’attendre à la fin du projet.

3. De la théorie à la pratique : établir l’architecture du système

Passons à présent aux détails pratiques. En partant du document de spécifications logicielles et de l’expérience utilisateur nouvellement créée, nous pouvons répertorier tous les systèmes et applications qui doivent être intégrés.

Par exemple, OpenText, CHILI publisher ainsi que d’autres outils pourraient tous être nécessaires dans le cas d’une solution de création de contenus pour l’entreprise. Peuvent également s’ajouter des outils comme des systèmes de gestion des ressources numériques (DAM), de gestion des informations produits (PIM) ou de gestion des contenus (CMS), lesquels devront tous être reliés d’une manière ou d’une autre.

Le projet devenant de plus en plus technique, nous chercherons également à comprendre certains facteurs clés, par exemple :

• Quels ports pour quels réseaux seront nécessaires pour que les systèmes puissent communiquer entre eux ?
• Quelle sera la charge réseau ? En termes de plateformes, de systèmes et d’utilisateurs ?
• Quelles mises à jour seront nécessaires pour les plateformes, les systèmes ou le réseau ?

Une fois que nous avons les réponses à ces questions et aux autres questions sur l’architecture, nous produisons un document reprenant l’architecture système proposée et nous le communiquons au client pour examen et approbation.

4. Conception technique

Nous voici à présent à l’étape 4 du processus, mais nous ne sommes pas encore tout à fait prêts pour les IDE et la programmation. À ce stade, nous avons encore besoin de comprendre parfaitement, et de soigneusement planifier et documenter chaque aspect technique de la conception. En nous assurant que les choses sont faites correctement en amont, nous évitons tout risque de problème de spécification plus tard, et nous évitons les clients mécontents.

Les étapes essentielles de cette phase de conception technique sont notamment les suivantes :

• Lister toutes les informations de métadonnées requises pour l’intégration, à la fois fonctionnelles et techniques.
• Trouver, tester et documenter la liste des API requises pour l’intégration ainsi que les intercepteurs. C’est ici que l’on voit tout l’intérêt de créer l’expérience utilisateur en amont. Bien conçue, elle nous fournit déjà la liste exacte des API nécessaires et des informations sur la façon dont les requêtes/réponses doivent apparaître de sorte qu’elles sont facilement traduisibles dans l’interface utilisateur proposée.
• Finaliser certaines choses comme savoir où la gestion des utilisateurs est traitée, comment le SSO fonctionnera, le fournisseur d’authentification, l’expiration des sessions, etc.

De nouveau, tous ces aspects techniques seront finalisés, documentés et envoyés au client pour examen et approbation. Dès qu’il s’agit de déployer des plateformes à l’échelle de l’entreprise comme OpenText et CHILI publisher, l’expérience et la bonne connaissance de ces outils sont un véritable atout pour créer une documentation technique complète.

5. Implémentation et livraison

Pour les projets d’entreprise, l’étape 5 d’implémentation et de livraison peut se révéler plus longue, mais elle est essentielle pour clarifier la portée du projet et répondre précisément aux exigences et aux attentes du client.

Avant toute implémentation, il est primordial de fixer les exigences et la conception du projet, puis que tous les points discutés en amont soient définitivement approuvés. Et après seulement, l’implémentation peut commencer.

Généralement, nous recommandons de suivre une méthodologie Agile pour la l’implémentation. Elle offre plus de flexibilité que les autres méthodes. En outre, le cas échéant, l’adoption de nouvelles exigences pendant l’implémentation sera plus facile avec Agile.

Utiliser Agile nous permet également de montrer la progression de notre travail à la fin de chaque sprint. C’est excellent pour tenir informées les différentes parties prenantes et cela permet de rester au plus près des attentes du client.

D’après notre expérience, nous observons souvent que les clients s’attendent à ce que 100 % de leurs exigences soient implémentées, testées et approuvées avant la mise en ligne. Cela ne fonctionne pas avec une approche Agile et plus généralement, cela ne marche presque jamais, dans la mesure où de nouvelles exigences ou améliorations interviennent régulièrement pendant la phase d’implémentation.

C’est pourquoi nous suggérons que la mise en ligne se fasse le plus tôt possible avec un Produit minimum viable (MVP). Une fois le site en ligne, l’équipe de développement d’Acheron peut toujours ajouter de nouvelles fonctionnalités et améliorations à cette version MVP. Cette approche permet en outre de traiter rapidement les retours de l’entreprise et de mettre à jour les nouvelles versions déployées à la fin de chaque sprint.

En résumé

Pour Acheron, le but d’une intégration OpenText est de résoudre les problèmes d’une entreprise et d’assurer un bon retour sur investissement à nos clients. Lorsque les clients ont besoin d’un projet de conception basée sur les contenus, nous utilisons CHILI publisher pour la puissance de ses outils, pour son ensemble complet d’API, ainsi que pour ses performances et sa stabilité. Les projets de ce type requièrent une planification minutieuse et bénéficient du recul que donne l’expérience.

Et parce que nous avons cette expérience d’intégration avec OpenText et CHILI publish, nous espérons que ce bref aperçu de notre manière d’aborder ce type de projets vous a donné matière à réflexion !