Mise en place d'une liaison avec un logiciel métier

Cette page est un guide visant à expliquer comment et à quelles étapes Entr'ouvert peut intervenir dans la mise en place d'une liaison entre un logiciel métier et Publik. Elle a été rédigée sur la base de la présentation effectuée lors du Club 2026 à Grenoble.

Le cas de figure envisagé :

1. une demande, saisie par un usager dans Publik, doit être transmis dans un logiciel métier
2. le traitement est effectué par les agents, en back-office, dans le logiciel métier
3. il est souhaité donner visibilité du traitement à l'usager.

Le déroulé suivant est axé sur la mise en place du « connecteur proxy générique » dans Publik mais certains aspects méthodologiques peuvent également s'appliquer à un connecteur ad-hoc qui serait développé spécifiquement par Entr'ouvert.

La demande de l'organisme, utilisateur de Publik

Ce qui est insuffisant

Une demande exprimée uniquement sous la forme « Publik dispose t'il d'un connecteur avec le logiciel "lambda" ? Si non, combien cela coûterait-il ? » est insuffisante. Pourquoi ?

• En premier lieu parce qu'il faut déjà savoir si le logiciel lambda expose une interface de programmation d’application (API).
• Il faut également un descriptif, même succinct, du cas d'usage du connecteur envisagé ; il ne doit pas être envisagé une liaison qui utiliserait tous les points de terminaison (endpoints) existants mais uniquement ceux nécessaires à l'objectif visé.

Sans ces deux éléments, au minimum, il est impossible de vous apporter une réponse.

Ce qui est nécessaire

L'expression du besoin et du cas d'usage inclura les éléments suivants : l'éditeur, le nom du logiciel (éventuellement module concerné et/ou version), une documentation (technique et fonctionelle, idéalement), une explication fonctionnelle du cas d'usage, l'URL du formulaire concerné dans Publik (si ce formulaire est déjà existant).

Ce qui est disponible

Pour votre propre réflexion et pour information de l'éditeur du logiciel métier, la page « Échanges avec un logiciel de gestion de demandes métier » est disponible ; c'est en ligne, notre documentation est sous licence Creative Commons attribution partage à l'identique 3.0, profitez-en.

L'idéal

En plus des éléments ci-dessus, le cas d'usage pourra être étayé des éléments suivants qui auront été posés par écrit après échanges avec le service métier et éventuellement l'éditeur :

• Descriptif des interactions avec l'usager (en amont lors de la qualification de la demande, dans le cours du traitement).
• La demande inclura t'elle des fichiers (justificatifs scannés, photos...) ?
• Y a t’il des référentiels possédés par le logiciel métier ?
• Quelle répartition envisagée entre les traitement effectués dans Publik et dans le logiciel métier (idéalement éviter que ce soit les mêmes agents qui travaillent et dans le back-office de Publik et dans le logiciel métier) ?
• Des fichiers (courriers, attestations...) doivent-ils être transmis à l'usager dans le cours ou à l'issue de sa démarche ?

Intervention d'Entr'ouvert auprès de l'organisme utilisateur

Une fois les éléments ci-dessus collectés et transmis à Entr'ouvert, une réunion de cadrage peut être envisagée ; d'autant plus si l'éditeur du logiciel métier développe une API pour utiliser nativement les webservices exposés par Publik. En l'absence d'éléments écrits préalablement transmis, Entr'ouvert se réserve le droit de ne pas participer à une telle réunion.

Entr'ouvert interviendra par contre obligatoirement en prenant connaissance d'une première version de la documentation transmise par l'éditeur (V0), documentation qui inclura idéalement une explication fonctionnelle des endpoints exposés.

Puis le déroulé complet des interactions Publik > logiciel métier > Publik devra avoir été discuté, posé par écrit et validé par tous les acteurs du projet (organisme utilisateur, éditeur métier, Entr'ouvert). Si un formulaire “démonstratif / martyr” n'existe pas encore sur l’instance de test, c'est le moment de le créer !

Mise en place de la liaison par l'éditeur métier et l'organisme utilisateur

Le préalable est l'existence d'une documentation, fournie par l'éditeur métier dans une version stable si ce n'est définitive. Si des modifications sont apportées à cette documentation, les versions ultérieures devront être clairement identifiées ou,encore mieux, la documentation sera accessible en ligne (sous forme d'un wiki ou autre) et alors versionnée. Cette documentation peut être transmise au format OpenAPI ("swagger"), exemple : https://preprod.testnca.org/MiseSousPliApi/swagger/index.html

L'éditeur ouvrira son API, iso-périmètre avec l'attendu en production y compris donc avec filtrage sur adresses IP et/ou authentification. La stabilité des APIs, en test comme en production, est primordiale car l’instance de test sera utilisée pour la mise en place mais aussi pour le support-maintenance et les éventuelles évolutions de la liaison, sur le long terme donc.

L'organisme utilisateur doit être au maximum autonome, avec son éditeur, pour la réalisation de son plan de tests :

• L’éditeur doit pouvoir déposer lui-même des demandes, pour ceci, il lui aura été expliqué le nécessaire indispensable pour la compréhension de la démarche à tester.
• L'organisme utilisateur aura paramétré son workflow pour exposer les erreurs et pouvoir rejouer aussitôt une demande par tous, y compris l’éditeur.
• Optionnellement, l'organisme utilisateur peut ouvrir, à l’éditeur, un accès avec les droits de testeur et d’ « Administrateur de Passerelle” (sur l'instance de test)

Entr'ouvert se tient à disposition, si nécessaire, pour chaque question qui sera transmise via un ticket ; ticket qui mentionnera précisément l'URL de la demande concernée, message d'erreur, logs... en cas d'erreur technique. Un échange en visio-conférence ne sera utile que dans rares cas de blocages, alors souvent plus fonctionnels que techniques.

Le passage en production est de la responsabilité de l'organisme utilisateur. Cette opération ne peut être envisagée que si la démarche en test est fonctionnelle, de bout en bout, pour tous les cas d’usages ; il faut absolument éviter les ajustements qui seraient à effectuer en parallèle, sur la production et sur la test.