Automatisation de la délivrance

Gros plan sur la connexion robot/ordinateur

Publié le 26/09/2011

Article réservé aux abonnés

Collaboration, complémentarité, ou à chacun son métier ? Comment s’établissent les rapports entre informatique (SSII) et automaticiens pour une coordination optimale ? Le Quotidien du Pharmacien donne la parole aux fabricants d’automates.

Attention aux bugs lors des mises à jour des logiciels
Crédit photo : doc. apoteka

Le mariage réussi du robot et de l’ordinateur
Crédit photo : Doc. ARX

1 Quelles sont les exigences techniques des installateurs pour que leurs machines tournent en phase avec le logiciel métier de l’officine ?

En France, un protocole de communication a été défini conjointement entre fournisseurs d’automatisation et SSII : c’est le protocole CDAPI. « Pour chaque projet, nous souhaitons que le titulaire, via son fournisseur informatique, dispose de l’ensemble des fonctions du cahier des charges du protocole CDAPI, explique François Legaud (Directeur commercial groupe Arx Rowa). De façon à valider ces aspects, nous fournissons à chaque nouveau client la liste des fonctions que son système Arx Rowa est à même d’utiliser, afin que son fournisseur informatique l’informe des options développées pour la version logicielle dont il dispose. Le client doit faire installer un câble de connexion entre le robot Rowa et le système de gestion de la pharmacie, ainsi que les logiciels nécessaires à l’interfaçage des deux systèmes. »

Même démarche rigoureuse chez Meditech : « notre première exigence est la conformité de la communication au protocole CDAPI, précise Vincent Deltour (Responsable marketing Meditech France). Lorsqu’un client achète une machine, notre première tache consiste à réaliser des tests de communication, et nous ne livrons pas la machine tant que ces tests ne sont pas validés ou que l’on constate que le logiciel métier ne répond pas à la demande. Nous jouons la transparence en précisant bien les fonctionnalités que le robot va lui fournir. Nous disposons d’un cahier des charges très précis pour chaque logiciel. »

2 Ces exigences sont-elles les mêmes pour les robots et les automates ?

Si pour Olivier Resano (Directeur commercial Apotéka), l’interface entre l’informatique et l’automate est un protocole de mise en place dont les exigences sont globalement les mêmes pour les robots et les automates, François Legaud estime que : « les robots offrent plus de possibilités de gestion de stock qu’un automate, les possibilités de gestion avec le logiciel de l’officine sont donc plus étendues. »

3 Quels sont les types de pannes qui peuvent survenir ?

Les problèmes peuvent être de deux types explique-t-on chez Arx. « Il peut s’agir d’un problème de liaison qui a été perdue entre le robot et le logiciel. Il faut alors relancer la procédure de connexion ou redémarrer les deux systèmes. Des problèmes peuvent également se produire lors de la mise à jour des logiciels du robot ou de la SSII, chaque mise à jour apporte son lot de bugs. »

Chez Apotéka et Meditech, on confirme que la panne principale est liée à la saturation du réseau. Un trop plein de messages crée un encombrement, il y a alors rupture de communication et il se produit un embouteillage au niveau du robot. Il faut alors relancer le serveur. « Ce type de panne est souvent dû à une sous-dimension du serveur en termes de capacité et de travail, le problème est hors robot », précise Vincent Deltour. Il est important que le commercial du logiciel gestion fasse une bonne évaluation du serveur au niveau de la pharmacie. Un autre problème peut survenir lors de la mise en place du réseau. Les installateurs de robot donnent un plan d’exécution détaillé du câblage, mais il peut y avoir des erreurs d’installation. Le raccordement des câbles réseaux aux serveurs et autres systèmes de l’officine reste à la charge du client.

4 Comment déterminer l’origine de la panne et la part de responsabilité de chacun des opérateurs ?

Les responsables techniques régionaux d’Arx font remonter les fiches d’échanges qui ont été produits pendant les communications robot-logiciel. Ces fiches sont analysées et les problèmes sont rapidement identifiés. « À défaut, les informations sont remontées et étudiées à la direction technique SAV d’Arx, conjointement avec la maison mère et la SSII concernée », remarque François Legaud.

Procédure similaire chez Apotéka : chaque pharmacie étant référencée dans le logiciel de SAV, l’opérateur de la hotline accède immédiatement à la connaissance de l’équipement complet de la pharmacie, son installation, son circuit électronique et électrique et son système informatique, et il peut déterminer l’origine de la panne et au besoin la résoudre à distance.

5 Quels sont les enjeux posés par l’intégration du datamatrix ?

« Cet enjeu capital dépend du type de machine d’automatisation utilisé », souligne-t-on chez Arx. Dans le cas du datamatrix, si tous les systèmes sont équipés de scanner permettant la lecture des codes 2D, toutes les machines utilisant, pour l’ensemble ou une part de leur architecture, une partie automate ne peuvent accéder aux boîtes une fois que celles-ci sont chargées dans les canaux, alors qu’un robot peut accéder à tout moment à n’importe quelle boîte du stock. « Le robot Rowa VMax peut « utiliser » les données lues en entrée pour chaque boîte et il range physiquement chaque boîte qu’il a identifiée, détaille François Legaud. La possibilité d’accéder à tout moment à l’ensemble du stock, lui offre une grande flexibilité et surtout, enjeu crucial du datamatrix, lui permet de garantir la traçabilité de chacune des boîtes délivrées. » Chez Meditech, le datamatrix est intégré d’office depuis un an et demi. « Nous apportons ainsi aux titulaires un gain de temps dans la gestion des périmés et des retraits de lots, et dans la délivrance avec l’assurance du bon prix boîte par boîte », remarque Vincent Deltour.

› CHRISTINE NICOLET