Norme de développement des applications clientes de journaux de bord électroniques (Version finale 6.0) - Juillet 2022

Version PDF (728 Ko)

1. Introduction

Le paragraphe 61(3) de la Loi sur les pêches autorise le MPO à imposer des conditions aux permis émis en vertu de cette loi, pour exiger que les pêcheurs tiennent un registre de leurs prises et de leurs efforts de pêche, et les communiquent au MPO. Jusqu’à maintenant, les pêcheurs rapportaient ces informations au moyen de documents papier.

Ce document de Pêches et Océans Canada défini les exigences à rencontrer au cours du développement des applications clientes de journaux de bord électroniques (JBE). Les applications clientes JBE permettront aux pêcheurs et aux fournisseurs de services de saisir et transmettre l’information des captures et des efforts de pêche du pêcheur au MPO au moyen de fichiers électroniques de type XML.

Les applications clientes JBE seront développées en 2 phases :

Phase 1 : Une première phase vise à rendre disponible les applications clientes JBE utilisées directement par les pêcheurs. Ceux-ci feront eux-mêmes la saisie des données de journaux de bord et déclencheront la transmission des données au MPO. Les données ne seront jamais modifiées manuellement par le fournisseur de service. Les données transmises au MPO représenteront intégralement ce qui a été transmis par le pêcheur même si une conversion automatique ou manuelle a lieu. Pendant la phase 1 les pêcheurs seront les seuls utilisateurs des applications JBE.

Phase 2 : La deuxième phase visera à évaluer la possibilité d’intégrer les données provenant d’un fournisseur de service qui aura été mandaté par le pêcheur pour effectuer la saisie ou la vérification/correction des données du pêcheur. Pendant la phase 2, les pêcheurs et les fournisseurs de service seraient les utilisateurs des applications clientes JBE. La phase 2 sera enclenchée ultérieurement.

Cette norme définit donc les caractéristiques, les processus et les meilleurs pratiques qui devront être prises en compte au cours du développement des applications clientes de journaux de bord électroniques. Cette norme servira de document de base lors du développement du processus de qualification des applications clientes JBE. Cette norme a été développée grâce au support de l’Office des normes générales du Canada (ONGC).

Le document des normes sera régulièrement revu et amendé au besoin afin de préciser certains points ou d’ajouter de nouveaux besoins relatifs aux applications clientes de journaux de bord électroniques.

2. Principes de la norme

Les principes suivants ont été utilisés afin de guider le développement de la présente norme :

2.1 Abordable

Il est primordial que les applications clientes JBE soient une option économique pour tous les intervenants impliqués dans les pêches canadiennes. Le respect des exigences de la norme ne devrait pas créer une pression financière indue sur les intervenants. Ce principe devrait être valide pour tous les intervenants impliqués dans le système national des journaux de bord électroniques du MPO, c’est-à-dire les pêcheurs, les fournisseurs de services, les développeurs d’applications clientes JBE et le MPO.

2.2 Innovation

La norme devrait être développée de manière à supporter l’innovation. Les intervenants devraient conserver leur capacité d’innover lorsqu’ils développent des applications clientes de journaux de bord électroniques. La norme devrait être développée de manière à clairement identifier les besoins des intervenants sans limiter excessivement les façons de répondre à ces besoins.

2.3 Flexibilité

La norme devrait être développée de manière à présenter des options qui permettront d’adapter les applications de journaux de bord électroniques aux réalités diverses des pêches canadiennes. La norme doit permettre de répondre aux besoins techniques, sociaux-économiques, pratiques et scientifiques de toutes les pêches canadiennes.

2.4 Intégrité

La norme devrait être développée de manière à s’assurer que l’intégrité des données soit toujours maintenue tout au long du processus de saisie, d’enregistrement, de traitement et de  transmission des données. La norme devrait être développée de manière à s’assurer que l’application cliente JBE enregistre correctement les données et que les données transmises du pêcheur jusqu’au MPO représente intégralement ce qui a été déclaré par le pêcheur, même si une conversion de données ou une conversion de fichier a eu lieu.

La norme devrait être développée de manière à ce que l’application cliente JBE n’empêche pas les utilisateurs de soumettre des informations pertinentes : Les applications clientes JBE devraient permettre la saisie, par exemple, de toutes les espèces capturées par le pêcheur, sans limitation du nombre d’espèces qu’il peut déclarer.

2.5 Sécurité

La norme devrait être développée de manière à s’assurer de la sécurité des informations qui sont transmises par l’application cliente JBE. La nature des informations qui sont transmises est sensible, il est donc primordial que tous les efforts soient faits afin de s’assurer qu’aucun préjudice ne soit causé à un intervenant par une perte de données ou un accès inapproprié aux données.

3. Structure XML des journaux de bord électroniques

La transmission des données de journaux de bord électroniques vers le système national des journaux de bord électroniques du MPO doit se faire uniquement au moyen de fichier XML (eXtensible Markup Language). Toutefois, un format de données différent peut être utilisé pour transférer les données entre le pêcheur et une infrastructure externe au MPO. Cette infrastructure devra convertir les données reçues, en fichier XML, et transmettre ces fichiers XML au système national des journaux de bord électronique du MPO.

Dans le but d’avoir une certaine uniformité dans la manière de rapporter l’information entre les régions du MPO et les différentes pêches, tous les fichiers XML devront être structurés sensiblement de la même façon. La « hiérarchie » des noeuds composant les fichiers XML sera donc la même pour tous les fichiers XML contenant des données de journaux de bord, peu importe la région ou le type de pêche.

Description pour le schéma JBE - Structure XML

3.1 Les noeuds XML

Dans le schéma « JBE- Structure XML » présenté ci-haut, les noeuds sont représentés par les rectangles.

Un noeud est un regroupement d’éléments de données. Un noeud peut être lié à zéro, un ou plusieurs noeuds-enfants. Lorsqu’un noeud-enfant est présent dans un fichier XML, tous les noeuds-parents de ce noeud-enfant doivent obligatoirement être présent dans le fichier XML.

Pour chaque type de pêche, chaque région du MPO a identifié les noeuds et les éléments de données qui composeront son journal de bord. Il est donc possible que, pour une même pêche, un noeud fasse partie du journal de bord pour une région mais pas pour une autre.

3.2 Les éléments de données

De façon générale, un élément de donnée est la plus petite information contenue dans un fichier XML.

L’élément de donnée contient l’information fournie par le pêcheur. (ex.: numéro du bateau, durée d’immersion, date de départ, etc.)

Chaque élément de données est lié à un noeud précis. 

Les éléments de données ne contenant pas d’information (contenu vide) ne doivent pas être inscrits dans le fichier XML.

Dans le fichier XML, les unités de mesure ont été standardisées, ainsi :

• les dates/heures devront être représentées en UTC
• les durées devront être représentées en minutes
• les positions utilisent le standard WSG84 et devront être représentées en degrés.décimales (4 décimales).
• les poids, les longueurs et les volumes devront être représentés en utilisant le système métrique (SI).

L’application cliente JBE peut permettre la saisie de la valeur d’un élément de données dans une unité de mesure différente de celle requise dans le fichier XML, mais, la valeur de cet élément, lorsqu’enregistrée dans le fichier XML, doit obligatoirement être représentée en utilisant l’unité de mesure identifiée dans le dictionnaire de données XML pour cet élément.

3.3 Le dictionnaire de données

Tous les éléments de données qui composent les journaux de bord électroniques ont été définis dans un dictionnaire de données. Ce dictionnaire décrit en détail chacun des éléments de données (description, type, longueur maximale, liste de valeur, format, présence de décimales, noeud d’appartenance, unité, etc.). Le dictionnaire de données est disponible sur demande en format CSV (Comma Separated Value) et en format .DOC (Les deux disponibles en version anglaise et française). Ces documents seront éventuellement disponibles sur le site extranet du MPO.

L’application cliente JBE devra s’assurer que les limites identifiées dans le dictionnaire de données ne seront pas excédées lors de la saisie. Ex.: Profondeur se situant entre 0 et 4500 mètres.

En fonction d’un contexte particulier, la fiche technique pourrait restreindre encore plus la liste des valeurs valides pour un élément de données.

3.4 Les formulaires

Un formulaire est un ensemble de noeuds et d’éléments de données qui composent un journal de bord. Il existe un formulaire par type d’engin de pêche, par région.

Pour chaque région, le formulaire indique si les éléments de données qu’il contient sont obligatoires ou optionnels.

La liste des éléments composant un noeud peut varier en fonction de la région, du type de pêche et de la version du formulaire.

En fonction de la région, du type d’engin de pêche et de la version du formulaire, un élément de données peut être soit:

1. Obligatoire : L’information d’un élément « obligatoire » DOIT être saisie par l’utilisateur si le noeud auquel appartient l’élément est utilisé. Si le noeud est utilisé, l’application cliente JBE DOIT s’assurer que l’utilisateur fournisse obligatoirement une valeur pour cet élément. Par exemple, si l’utilisateur veut inscrire un appel en mer, il utilisera le noeud HLIN et devra compléter, au minimum, les éléments « obligatoires » de ce noeud.
   Si le noeud auquel appartient l’élément n’est pas utilisé, l’utilisateur n’a pas à saisir cette information dite obligatoire.
   Cet élément doit être disponible dans les écrans de saisie.
2. Optionnel : L’information d’un élément « optionnel » PEUT être saisie, mais l’absence de saisie ne provoquera pas d’erreur.
   Cet élément doit être disponible dans les écrans de saisie.
   La saisie de cet élément pourrait devenir obligatoire en fonction d’un contexte particulier. Ces cas seront documentés dans les fiches techniques et/ou dans les conditions de permis, si applicable.

Seuls les éléments identifiés « Optionnel » ou « Obligatoire » pour un formulaire d’une région pourront être inclus dans les fichiers XML correspondant.

Dans l’application cliente JBE, tous les éléments « optionnels » ou « obligatoires » du formulaire devront pouvoir être saisis (ou modifiés) et confirmés par l’utilisateur. Cette règle ne s’applique cependant pas pour les éléments de données identifiés dans l’Annexe B : Éléments de données non-modifiables par l’utilisateur

Le respect des spécifications du formulaire fera généralement en sorte que le fichier XML sera accepté par le MPO et qu’il passera le processus de validation du MPO avec succès.

Sauf en cas de force majeure (ex. : nouvelle politiques, besoins exceptionnels, problème, etc.), le MPO tentera de limiter le plus possible les changements apportés aux formulaires (structure XML) afin de minimiser les impacts du côté des pêcheurs, des fournisseurs de services et des développeurs d’applications.

Les noms des formulaires qui existent présentement sont les suivants :

• JBE - Journal de bord – Chaluts *
• JBE - Journal de bord - Casiers (sauf homard)
• JBE - Journal de bord - Casiers (homard) *
• JBE - Journal de bord - Filets maillants
• JBE - Journal de bord - Baril
• JBE - Journal de bord - Trappe en filet, verveux
• JBE - Journal de bord - Ligne à main, canne à pêche, ligne tendue
• JBE - Journal de bord - Palangre
• JBE - Journal de bord - Plongée (sauf Pacifique)
• JBE - Journal de bord - Cueillette manuelle
• JBE - Journal de bord - Dragues
• JBE - Journal de bord - Filet maillant (saumon - Région du Pacifique)
• JBE - Journal de bord - Ligne traînante, senne (saumon - Région du Pacifique)
• JBE - Journal de bord - Sennes
• JBE - Journal de bord - Harpon, hakapik, gourdin, arme à feu
• JBE - Rapport d'observation de mammifères marins
• JBE - Journal de bord - Engins divers (omble chevalier - région C&A)
• JBE - Journal de bord - Plongée (Pacifique)

* présentement en usage dans le cadre du projet pilote

La définition des formulaires est disponible, en format de fichier CSV, sur demande et éventuellement sur le site extranet du MPO.

3.5 Les XSD

Pour chaque version de formulaire, il existe un fichier XSD (XML Schema Definition) permettant de valider grossièrement la structure du fichier XML. La validation avec le XSD se limitera à vérifier que les noms des noeuds et des éléments sont conformes à ce qui est attendu, que le type de donnée de chaque élément est respecté, que certaines valeurs limites soit respectées et que l’ordre d’inscription des éléments dans le fichier XML est le bon.

L’application cliente JBE devra vérifier que les fichiers XML qu’elle génère respectent les spécifications édictées par le XSD avant de transmettre un fichier XML au MPO. Un rejet provoqué par cette validation devra empêcher de transmettre le fichier XML au MPO.

Les fichiers XSD sont disponibles sur demande et éventuellement sur le site extranet du MPO.

3.6 Les groupes de données

Les informations liées à un journal de bord peuvent être transmises en utilisant plus d’un fichier XML. Cependant, certaines règles doivent être respectées lors de la création des fichiers XML. Ainsi, certains blocs d’informations ne peuvent être morcelés. La structure XML a donc été séparée en plusieurs groupes de données. Ces groupes, lorsqu’ils sont transmis, doivent être complets et finaux. Cela signifie qu’aucune information du groupe ne sera retransmise dans le but d’ajouter ou de modifier de l’information dans ce groupe.

Description pour le schéma JBE - Groupes de la structure XML

Lorsqu’un noeud est présent dans un fichier XML, tous ses noeuds-parents (jusqu’au noeud ELOG) doivent aussi être présent.

3.7 Nom des fichiers XML

Exemple : 1006-8521-20150603221030.XML

3.8 Jeux de caractères

Le jeu de caractères qui doit être utilisé pour générer les fichiers XML est l’UTF-8. Les accents français doivent être supportés correctement.

4. Enregistrement des données

L’application cliente JBE utilisé par le pêcheur devra pouvoir emmagasiner les données saisies par le pêcheur même si aucun lien de communication externe n’est fonctionnel.

5. Fermeture d’un groupe de données

La fermeture d’un groupe de données est le processus par lequel un utilisateur vérifie les données d’un groupe de données et confirme que ces données sont complètes et finales et qu’elles peuvent être transmises au MPO.

Les groupes de données sont identifiés dans la section 3.6 « Les groupes de données ».

Les groupes de données qui nécessiteront une option de fermeture seront identifiés dans la fiche technique de chaque formulaire.

Pour certaines flottes, les conditions de permis peuvent exiger que certaines parties du journal de bord soient complétées avant l’arrivée au quai. Lorsque cela est le cas et que l’utilisateur est un pêcheur, l’application cliente JBE devra offrir la possibilité de fermer les groupes de données correspondant aux parties du journal de bord qui doivent être complétées avant l’arrivée au quai.

Si une modification aux données d’un groupe de données fermé est nécessaire, l’utilisateur devra communiquer directement avec le MPO afin de transmettre sa demande de modification. L’application cliente JBE ne devra jamais retransmettre automatiquement une modification effectuée sur un groupe de données fermé antérieurement.

Si le formulaire l’exige, la date et l’heure (UTC) de fermeture du groupe de données devront être inscrites dans le fichier XML, dans le noeud principal du groupe de données.

5.1 Règles de fonctionnement liées à la fermeture des groupes de données

1. Un groupe de données ne sera fermé qu’une seule fois.
2. L’application cliente JBE devra permettre à l’utilisateur de visualiser toutes les informations du groupe de données qui sera fermé avant qu’il confirme la fermeture de ce groupe de données.

3. Les statuts possibles pour un groupe de données se limitent aux suivants :

   Ouvert : Groupe de données n’ayant pas été fermé.

   Fermé : Groupe de données fermé avec succès. Le groupe de données n’a pas été transmis au MPO.

   Transmis : Groupe de données fermé et transmis au MPO avec succès.

   Modifié : Le groupe de donnée a été modifié suite à sa transmission avec succès au MPO. Les changements effectués à un groupe de données « Ouvert » ne déclencheront pas un changement de statut à « Modifié ».

4. Le statut d’un groupe de données ne pourra passer que de « Ouvert » à « Fermé », de « Fermé » à « Transmis » et de « Transmis » à « Modifié ».
5. L’application cliente JBE devra obligatoirement permettre à l’utilisateur de modifier les données d’un groupe de données tant que le statut du groupe de données est « Ouvert ».
6. L’application cliente JBE devra obligatoirement interdire la modification des données d’un groupe de données tant que le statut du groupe de données est « Fermé ».
7. L’application cliente JBE pourra optionnellement permettre à l’utilisateur de modifier les données d’un groupe de données lorsque le statut du groupe de données est « Transmis » ou « Modifié ». Le détenteur des droits de l’application déterminera si son logiciel client JBE permettra aux utilisateurs de modifier les données locales d’un groupe de données ayant le statut « Transmis ». Le MPO n’exige pas que l’application cliente JBE permette la modification des données d’un groupe de données ayant le statut « Transmis ».
8. Si l’utilisateur modifie les données d’un groupe de données après qu’il ait été transmis avec succès au MPO, le statut du groupe de données deviendra « Modifié » au lieu de « Transmis ». Les données d’un groupe de données ayant le statut « Modifié »  ne doivent jamais être transmises au MPO par l’application. (Voir la section 14 « Correction des données déjà transmises »)
9. Le statut d’un groupe de données doit être affiché et clairement repérable.
10. La fermeture d’un groupe de données doit être possible même si aucun lien de communication externe n’est opérationnel.

L’annexe A présente des schémas illustrant le fonctionnement du processus de fermeture des groupes de données. Ces schémas sont montrés seulement pour aider à comprendre le processus de fermeture des groupes de données et du processus de transmission des groupes de données.

5.2 Vérification des données

Lors de l’étape de vérification des données, celles-ci devront être affichées en utilisant la même unité de mesure que celle utilisé au moment de la saisie. Les unités de mesure utilisées pour la vérification des données peuvent être différentes de celles spécifiées dans le dictionnaire de données. Toutefois, la valeur inscrite dans le fichier XML doit être représentée en utilisant l’unité de mesure spécifiée dans le dictionnaire de données.

L’étape de vérification devra permettre à l’utilisateur de visualiser TOUTES les données du groupe de données (et de ses parents) qui seront fermés.

6. Valeurs par défaut

L’application cliente JBE peut faire usage de valeurs par défaut pour certains éléments de données.

Lorsque les valeurs par défaut sont utilisées, elles doivent être affichées, être modifiables par l’utilisateur et être confirmées par l’utilisateur. Cette règle ne s’applique cependant pas pour les éléments de données identifiés dans l’Annexe B : Éléments de données non modifiables par l’utilisateur.

À l’exception des éléments de données identifiés à l’annexe B, aucune donnée faisant partie du journal de bord ne doit être générée automatiquement sans que l’utilisateur n’ait la possibilité de confirmer cette donnée.

7. Génération d’un identifiant unique de journal de bord

L’application cliente JBE devra générer un nouvel identifiant unique de journal de bord aussitôt qu’un nouveau journal de bord est créé.

L’identifiant unique du journal de bord sera composé d’une suite aléatoire de six caractères alphabétiques. Les caractères autorisés pour composer cet identifiant sont les lettres majuscules de A à Z. L’identifiant unique du journal de bord comportera toujours 6 caractères. Ex.: ARJHYE

L’identifiant unique du journal de bord devra être généré de manière aléatoire par l’application cliente JBE et sera inscrite dans l’élément LGBK_UID du noeud TRIP du fichier XML.

L’application cliente JBE devra être testée par le développeur afin de s’assurer qu’aucun doublon ne soit produit lors de la génération de 50 000 identifiants uniques de journal de bord.

Cet identifiant sera utilisé pour relier des documents provenant d’autres sources (ex.: sommaire de pesée, récépissé d’achats, appels) au journal de bord. L’identifiant unique du journal de bord doit donc être facilement repérable par le pêcheur.

8. Langue et Accessibilité

Les applications doivent obligatoirement être développées dans les deux langues officielles : l'anglais et le français.

* Voir la section 20 « Support technique » de ce document pour les exigences en matière de langue au niveau du support technique.

* Voir la section 21 « Guide de l’usager » de ce document pour les exigences en matière de langue au niveau du guide de l’usager.

Idéalement, les applications devraient être rendues accessibles à toutes les personnes, y compris, mais sans s'y limiter, les personnes avec de handicaps visuels, auditifs et cognitifs. Vous trouverez ci-dessous des directives d'accessibilité recommandées que les développeurs doivent prendre en compte pendant le développement de leurs applications :

1. Langage clair - il est recommandé que toutes les informations écrites soient fournies en phrases courtes, en utilisant une voix active avec des mots du quotidien qui évitent le jargon technique. 
2. Accessibilité numérique - il est recommandé que les sites web et les applications soient conçus de manière à être visuellement conviviaux et accessibles. Pour améliorer l'accessibilité numérique, les développeurs peuvent tenir compte des lignes directrices suivantes :
• Accessibilité visuelle - permettre l'utilisation de lecteurs d'écran, d'affichages en braille, de fonctions d’élargissement et raccourcissement, de contrastes élevés, etc. L'utilisation de galeries de styles fournies par la plupart des programmes de traitement de texte peut aider les lecteurs d'écran à naviguer dans les informations.
• Accessibilité auditive - y compris les sous-titres et les transcriptions.
• Accessibilité cognitive - utilisation de mises en page très organisées et visuellement conviviales. Les sections incluses dans les formulaires doivent être clairement étiquetés.

Pour plus d’informations sur les directives visant à promouvoir l'accessibilité des ressources numériques, veuillez consulter la ressource suivante fournie par Normes d'accessibilité Canada.

9. Vérification des journaux de bord

Les utilisateurs de l’application cliente JBE qui sont des pêcheurs, ou des personnes autorisées par le pêcheur devront être capables de visualiser au moins les données inclues dans les deux derniers journaux de bord créé, sans tenir compte du fait que le journal de bord ait été transmis ou non ou que le lien de communication soit fonctionnel. Tout besoin de conserver plus de journaux de bord disponibles pour vérification, par exemple, en fonction des exigences de l’OPANO, seront documentés dans la fiche technique applicable.

10. Interférence

Les interférences sont les problèmes de cohabitation physique ou logicielle de l’application avec son environnement. Les équipements requis par l’application cliente JBE ne doivent pas interférer avec les équipements du navire. Ils ne doivent pas altérer le fonctionnement ou arrêter les opérations du navire ou des équipements du navire. (Ex.: GPS)

L’application cliente JBE doit être développée de manière à fonctionner dans diverses conditions physiques, géographiques et climatiques. La disponibilité d’une couverture cellulaire dans la région à desservir, les conditions climatiques défavorables, la couverture nuageuse, le peu ou l’absence d’espace dans la cabine, etc., en sont quelques exemples. Certaines contraintes connues pourraient être identifiées dans la fiche technique. Ces contraintes devront être prises en compte durant le développement de l’application cliente JBE.

11. Coordonnées (latitude/longitude)

L’application cliente JBE devra obligatoirement permettre de saisir manuellement chaque coordonnée (latitude et longitude).

La lecture directe d’une coordonnée à partir d’un GPS, quoi que souhaitable, est optionnelle. L’application cliente JBE peut ne pas offrir cette fonctionnalité.

11.1 Saisie manuelle

Pour toutes les coordonnées, l’application cliente JBE devra permettre à l’utilisateur de saisir manuellement une valeur pour la latitude et la longitude. L’utilisateur devra pouvoir inscrire une valeur dans les deux éléments composants la coordonnée, soit la latitude et la longitude.

La saisie manuelle de coordonnées par l’utilisateur demeure possible même si les coordonnées ont été obtenues initialement à partir d’un GPS.

11.2 Lecture du GPS

La lecture d’une coordonnée à partir d’un GPS ne sera disponible que si l’utilisateur est un pêcheur.

L’application cliente JBE peut offrir au pêcheur la capacité de lire la latitude et la longitude à partir du GPS suite à une action du pêcheur (ex.: Le pêcheur appuie sur un bouton de lecture de la coordonnée). Si cette fonctionnalité est disponible, les valeurs retournées par le GPS seront inscrites automatiquement dans les champs prévus à cet effet par l’application. L’application cliente JBE doit permettre au pêcheur de modifier manuellement ces champs de données.

11.3 Attribut décrivant le mode utilisé

Pour chaque élément du fichier XML représentant une coordonnée, un attribut XML (MODE="M" ou MODE="G") devra être juxtaposé à l’élément XML pour indiquer le mode utilisé par l’utilisateur pour affecter une valeur à la coordonnée:

Exemple :

Lorsqu’une modification est apportée manuellement à un des éléments de la coordonnée, son mode devient ‘M’ afin d’indiquer que cette entrée a été modifiée manuellement.

Lorsqu’une coordonnée est initialisée à partir du GPS, son mode devient ‘G’ afin d’indiquer que cette entrée a été initialisée à partir du GPS.

12. Début de voyage

12.1 Vérification de l’état des groupes de données

La section 12.1 ne s’applique que si l’utilisateur n’est pas un fournisseur de service.

L’utilisateur sera obligé de fermer les groupes de données du voyage précédent avant de créer un nouveau voyage. Par contre, il ne sera pas obligé de « transmettre » ses données au MPO avant de créer un nouveau voyage.

Avant de créer un nouveau voyage, l’application cliente JBE devra vérifier que les groupes de données des voyages précédents ont tous été fermés. Si ce n’est pas le cas, un message d’erreur devra en aviser l’utilisateur.

Avant de créer un nouveau voyage, l’application cliente JBE devra vérifier que les groupes de données des voyages précédents ont tous été transmis au MPO. Si ce n’est pas le cas, un message d’avertissement devra en aviser l’utilisateur. L’application cliente JBE ne devra jamais interdire la création d’un nouveau voyage.

12.2 Vérification des informations de base

Lors de la création d’un nouveau voyage, l’utilisateur devra pouvoir vérifier et confirmer que les informations de base qu’il utilise sont les bonnes, à savoir :

• le nom du capitaine
• Le numéro d’identification du détenteur de permis (NIP)
• Le numéro du bateau (NEB)
• Le numéro du permis utilisé
• La date et l’heure courante

13. Transmission des données

Le processus de transmission des données est l’opération qui consiste à transférer, de façon sécuritaire, les données de journaux de bord de l’utilisateur vers le MPO et à s’assurer que le transfert s’est bien effectué. Cette fonction devra mettre à jour un registre des transmissions propre au pêcheur. (Voir la section 13.3 « Registre des transmissions »)

La transmission des données de journaux de bord électroniques vers le système national des journaux de bord électroniques du MPO doit se faire uniquement au moyen de fichier XML. Toutefois, un format de données différent peut être utilisé pour transférer les données entre le pêcheur et une infrastructure externe au MPO qui convertira les données reçues, en fichier XML, et transmettra ces fichiers au système national des journaux de bord électronique du MPO. (Voir la section 13.7 « Utilisation d’un format de données différent du XML »)

Une copie électronique de chaque fichier XML transmis avec succès au MPO devra être conservée. (Voir la section 13.4 « Archivage du fichier XML» )

Les fichiers XML seront transmis au MPO en utilisant un service WEB du MPO disponible 24/24. Des informations complémentaires concernant le service Web seront fournies sur demande au MPO.

L’application cliente JBE devra disposer d’un mécanisme permettant la reprise d’une transmission n’ayant pas été complétée avec succès. Par exemple, si aucun lien de communication externe n’est disponible au moment où l’utilisateur désire transférer ses données ou si le service Web ne répond pas ou s’il retourne une erreur de transmission.

Si un formulaire inclut une section permettant d’effectuer des rapports quotidiens (noeud « DAILY_REPORT »), l’application cliente JBE devra offrir la possibilité de ne transmettre que la portion « rapport quotidien » du journal de bord. Les noeuds transmis dans ce type de transmission devront donc être uniquement les noeuds ELOG, TRIP, DAILY_REPORT, DR_GRP et DR_DETAIL.

13.1 Obtention d’une clé JBE

Avant de transmettre ses données pour la première fois au MPO, le pêcheur (ou le fournisseur de service) devra préalablement s’être identifié(e) auprès du MPO comme un utilisateur de journal de bord électronique. Il (elle) devra ensuite créer et configurer sa clé JBE.

Une seule clé JBE sera émise pour un fournisseur de service. La même clé JBE sera utilisée par tous les employés de ce fournisseur de service.

Pour obtenir une clé JBE,

1. Le pêcheur, ou le fournisseur de service, devra accéder le site internet du Ministère, onglet Pêches, sous-menu Pêches commerciales, option Journaux de bord électroniques). Au cours de ce processus, le pêcheur devra s’identifier auprès du MPO.
2. Le pêcheur, ou le fournisseur de service, devra créer sa clé JBE en utilisant les options disponibles du site Internet du MPO. La clé JBE sera alors affichée à l’écran.
3. La clé JBE du pêcheur, ou du fournisseur de service, devra être copiée manuellement dans l’application cliente JBE.

La clé JBE fait en sorte que les pêcheurs, ou les fournisseurs de service, n’ont à s’authentifier qu’une seule fois. L’application cliente JBE devra inclure la clé JBE dans chaque transmission de données destinée au MPO. (Voir section « 13.2 Le service Web »

L’application cliente JBE doit pouvoir conserver la clé de façon sécuritaire. Une fois enregistrée dans l’application cliente JBE, la clé JBE ne devra plus être visible à l’utilisateur.

La clé JBE doit pouvoir être remplacée dans l’application. Au besoin, un pêcheur, ou un fournisseur de service, peut générer une nouvelle clé JBE via le site WEB du MPO. En conséquence, l’application cliente JBE doit avoir la capacité de remplacer une clé JBE enregistrée antérieurement.

Les clés inutilisées depuis plus de 1 an seront automatiquement désactivées au MPO.

13.2 Le service Web

L’application cliente JBE utilisera un service WEB du MPO lors de la transmission des données de journaux de bord électroniques au MPO.

Ce service WEB utilisera une connexion sécurisée de type HTTPS (HyperText Transfer Protocol Secure) dans laquelle transitera une enveloppe SOAP. En plus du fichier XML, l’enveloppe SOAP inclura la clé JBE et le nom du fichier.

Afin de réduire la quantité d’information en transit, le fichier XML peut être préalablement compressé à l’aide de l’utilitaire 7zip. Si le fichier est compressé, l’extension du nom du fichier sera .7z au lieu de .XML

Lorsqu’un fichier sera reçu par le service Web, celui-ci validera le contenu de l’enveloppe SOAP afin de s’assurer que l’expéditeur est bien autorisé à envoyer des fichiers JBE et que le contenu est bien ce qu’on s’attend qu’il soit, soit un fichier XML de JBE ou un fichier compressé contenant un fichier XML de JBE. Quelques validations supplémentaires sont aussi effectuées par le service WEB à cette étape.

Si une erreur est détectée, un fichier XML contenant le numéro de confirmation de la transmission et le code d’erreur sera retourné par le service Web. Aucune autre information ne sera retournée. Les messages correspondant aux codes d’erreurs seront rendus disponibles par le MPO aux développeurs afin d’être inclus dans l’application cliente JBE.

Si aucune erreur n’est détectée, un fichier XML contenant les informations suivantes sera retourné en réponse: le numéro de confirmation de la transmission, le code d’erreur, le numéro du bateau, le numéro d’identification du pêcheur (NIP) et l’identifiant unique du journal de bord. Le code d’erreur contiendra WS0000 si aucune erreur n’est détectée par le service Web.

L’application devra décoder et communiquer clairement la réponse reçue du service WEB à l’utilisateur (succès ou échec).

13.3 Registres des transmissions

L’application cliente JBE devra enregistrer le résultat de toutes les tentatives de transmission de données de journaux de bord électroniques dans un registre des transmissions. Il existe deux types de registres des transmissions : Registre des transmissions avec utilisation du service Web du MPO et Registre des transmissions sans utilisation du service Web du MPO.

13.3.1 Registre des transmissions avec utilisation du service Web du MPO :

Ce type de registre devra être utilisé si l’information transmise est envoyée directement au MPO, donc, si la transmission « utilise » immédiatement le service Web du MPO, par exemple, transmission directe du poste de travail vers le MPO sans utilisation d’infrastructure externe ou dans le cas d’une transmission à partir d’une infrastructure externe vers le MPO.

Le logiciel client JBE devra conserver le résultat de chaque tentative de transmission utilisant le service Web du MPO dans ce type de registre.

Le registre devra inclure au minimum :

• Le numéro de confirmation de transmission (retourné par le service Web)
• La date et l’heure de la tentative de transmission (UTC)
• Le nom du fichier XML transmis
• Le statut de la transmission (« Échec » ou « Succès »)
• Le message d’erreur (si applicable)
• L’identifiant unique du journal de bord
• Le numéro de voyage
• Le numéro du bateau
• Le résultat de validation XSD effectuée par le logiciel client (« Erreur »  ou « Succès » ou « S/O »)

Ces informations devront être conservées dans le système du client afin d’être disponibles pour consultation par l’utilisateur. Les informations concernant les tentatives infructueuses de transmission doivent aussi être conservées dans ce registre par l’application cliente JBE.

Les informations contenues dans ce type de registre des transmissions doivent être archivées et accessibles pour une période de trois ans suivant la tentative de transmission. Les registres des transmissions archivés peuvent être conservés sur la station de travail de l’application ou sur un équipement externe.

13.3.2 Registre des transmissions sans utilisation du service Web du MPO :

Ce type de registre devra être utilisé si l’information transmise à partir du poste de travail n’est pas directement destinée au MPO, donc, si la transmission « n’utilise pas» immédiatement le service Web du MPO.

Quoique la transmission au MPO se fasse toujours en utilisant le service Web du MPO, il est possible qu’une transmission à partir d’un poste client doive d’abord transiter par une infrastructure externe avant que les données ne soient retransmises au MPO à partir de l’infrastructure externe. Puisque cette transmission faite à partir du poste de travail vers une infrastructure externe n’impliquera pas le service Web du MPO, les informations retournées par le service Web ne seront pas disponibles au moment de la transmission. Dans ce cas, le résultat de la transmission entre le poste de travail et l’infrastructure externe devra être conservé dans un « registre des transmissions sans utilisation du service Web du MPO » et le résultat de la transmission entre l’infrastructure externe et le MPO devra être conservé dans un « Registre des transmissions avec utilisation du service Web du MPO ».

Si le service Web du MPO n’est pas utilisé directement lors de la transmission, le logiciel client JBE devra conserver le résultat de chaque tentative de transmission dans ce type de registre.

Le registre devra inclure au minimum :

• La date et l’heure de la tentative de transmission (UTC)
• Le statut de la transmission (« Échec » ou « Succès »)
• Le message d’erreur (si applicable)
• L’identifiant unique du journal de bord
• Le numéro de voyage
• Le numéro du bateau

Les informations concernant les tentatives infructueuses de transmission doivent aussi être conservées dans ce registre.

Les informations contenues dans ce type de registre doivent demeurer accessibles pour une période de trente jours suivant la tentative de transmission. Pour ce type de registre, aucun archivage des résultats de tentatives de transmissions datant de plus de trente jours n’est requis.

13.3.3 Consultation des transmissions effectuées dans les trente derniers jours.

L’application cliente JBE doit permettre à l’utilisateur d’afficher le résultat des tentatives de transmissions effectuées dans les trente jours précédents, et ce, à partir de l’un ou l’autre de ces registres, même si le lien de communication n’est pas fonctionnel.

13.4 Archivage du fichier XML

L’archivage du fichier XML consiste à conserver une copie électronique du fichier XML suite à sa transmission avec succès au MPO. Les fichiers XML archivés ne seront jamais mis à jour ou détruits, ni par une personne, ni au moyen d’un quelconque logiciel une fois qu’ils ont été archivés et ce, pour une période de trois ans.

Advenant un cas de cour, ces fichiers pourraient être exigés pour vérifier les données transmises par les utilisateurs.

La modification et la destruction des fichiers XML archivés sont interdite pendant les trois années suivant leur transmission. Passé ce délai, les fichiers XML archivés pourront être effacés définitivement.

Les fichiers XML archivés peuvent être conservés sur la station de travail ou sur un équipement externe.

Le schéma de la section A-1.3 montre le processus d’archivage durant processus de transmission.

13.5 Fréquence de transmission

Les exigences concernant les fréquences de transmission peuvent varier en fonction des besoins du MPO ou des limites imposées par la technologie dans certaines régions (ex. : besoins en terme de suivi, zone de couverture insuffisante en matière de télécommunication, géomorphologie, etc.). Les besoins en matière de fréquences de transmission seront précisés dans la fiche technique ainsi que dans la condition de permis attribuée au pêcheur en fonction de la pêche.

L’application devra permettre de respecter les contraintes imposées dans les fiches techniques et dans les conditions de permis impliquées.

Un même groupe de données (Voir la section 3.6 « Les groupes de données ») ne doit être transmis qu’une seule fois.

13.6 Délai de transmission

Il ne doit pas y avoir de délais inutiles suite au déclenchement de la transmission des données par l’utilisateur. Les données devront parvenir au MPO dans les plus brefs délais en tenant compte des limitations technologiques (ex. : indisponibilité d’un lien de communication, mauvaise qualité du lien de communication, bris d’équipement, panne électrique, indisponibilité de service Web, etc.).

L’utilisation d’une infrastructure externe ne doit pas générer de temps de latence, i.e., de délais avant la transmission au MPO, pendant lesquels les données ne sont pas traitées.

13.7 Utilisation d’un format de données différent du XML

Afin de minimiser les coûts et/ou d’augmenter la performance de la transmission des données, le MPO autorise l’utilisation d’un format de données différent du XML pour la transmission des données entre le l’utilisateur et une infrastructure externe au MPO. Si cette alternative est retenue, l’application cliente JBE devra inclure un module de conversion des données afin de créer les fichiers XML qui seront transmis au MPO.

Suite à la conversion, le fichier XML résultant devra représenter intégralement ce qui a été déclaré par le pêcheur. Le module de conversion ne doit jamais : créer une information qui n’a pas été fournie par le pêcheur, à l’exception des informations identifiées à l’annexe B; interpréter l’information fournie par le pêcheur de manière à en changer la signification; accroître la précision de l’information fournie par le pêcheur.

Le titulaire des droits de l’application cliente JBE sera responsable du développement et de l’entretien du module de conversion des données.

14. Correction des données déjà transmises

L’application cliente JBE ne devra jamais retransmettre un groupe de données ayant déjà été transmis avec succès au MPO (ni une copie de ce groupe de données contenant les modifications).

Lorsque la modification d’une donnée appartenant à un groupe de données déjà transmis survient, l’application devra signaler à l’utilisateur qu’il doit contacter le MPO pour demander une correction de ses données. Les corrections dans la base de données du MPO seront effectuées par les employés du MPO.

15. Mise à jour de l’application cliente JBE

L’application cliente JBE et ses composantes devront pouvoir être mis à jour.

Lorsque les tables de codes seront modifiées par le MPO, ces modifications devront être répercutées sur l’application cliente JBE. La mise à jour des tables de codes de l’application cliente JBE devra être effectuée par l’application cliente. Ces mises à jour ne requerront pas l’approbation du MPO ou de l’autorité désignée.

Lorsque les fichiers XSD seront modifiés par le MPO, ces modifications devront être répercutées sur la solution cliente La mise à jour des fichiers XSD de l’application cliente JBE devra être effectuée par l’application cliente. Ces mises à jour ne requerront pas l’approbation du MPO ou de l’autorité désignée.

Un nouveau numéro de version doit identifier de manière unique chaque version de l’application cliente JBE soumise au processus de qualification (ou mise en production dans le cas où une qualification de la nouvelle version ne serait pas requise).

Le nombre de mise à jour de l’application cliente JBE n’est pas limité. Par contre, les nouvelles versions devront être émises avec parcimonie, principalement en pleine saison de pêche.

Lorsqu’une nouvelle version d’un formulaire deviendra disponible, le MPO définira une date d’expiration pour les anciennes versions du formulaire. Le MPO n’acceptera pas les fichiers transmis qui sont basés sur une version expirée du formulaire.

16. Qualification des applications clientes JBE

La qualification consistera à vérifier que l‘application cliente JBE se conforme à la norme de développement. Cette vérification sera effectuée par le MPO. Les détails touchant le processus de qualification seront décrits dans un document séparé.

Une copie ou un accès à l’application cliente JBE devra être disponible sans frais sur demande du MPO afin d’en effectuer la vérification. 

Si l’application cliente JBE est un système partiellement ou totalement centralisé sur un serveur externe, un environnement de test devra être configuré et être disponible pour le MPO.

17. Instructions

Les applications clientes JBE devront être accompagnées des « instructions». Les instructions seront conservées dans un document indépendant du guide de l’usager.

Le titulaire des droits de l’application cliente JBE est responsable de produire ce(s) document(s).

Les instructions du fournisseur sont destinées aux utilisateurs des applications clientes JBE. Elles apportent des précisions sur la façon de compléter le journal de bord en fonction de ce qui est demandé par le MPO. Les conditions de permis réfèreront à ces instructions au besoin. Les instructions peuvent être présentées sous plusieurs formes (document(s), fonctionnalité d’aide, etc.). Elles devront cependant toujours être accessibles par l’utilisateur même si aucun lien internet n’est fonctionnel.

Le titulaire des droits de l’application cliente JBE devra être en mesure de fournir les « instructions du fournisseur » dans les mêmes langues que celles disponibles dans son application.

18. Fiches techniques

Les fiches techniques fournissent de l’information destinée aux développeurs d’application cliente JBE.

Une fiche technique est créée pour chaque version d’un formulaire. Elle contient, entre autres choses, certaines règles fonctionnelles spécifiques au formulaire ou aux flottes utilisant le formulaire.

L’application cliente JBE doit respecter les règles fonctionnelles édictées dans la fiche technique liée à la version de formulaire utilisé.

Les fiches techniques seront disponibles sur le site extranet du MPO.

19. Sécurité

La sécurité touche plusieurs volets, mais de façon générale, l’application cliente JBE devra s’assurer de mettre en place l’infrastructure nécessaire à la protection des données qu’elle traite.

Les données de journaux de bord électroniques transmises au moyen de l’application cliente JBE sont confidentielles et sujettes aux dispositions des lois fédérales et provinciales applicables. Par conséquent, les données de journaux de bord électroniques doivent être protégées contre la divulgation non autorisée et l’accès par des tiers autres que le MPO et le pêcheur duquel elles proviennent. La divulgation ou l’accès aux données par un tiers autre que le pêcheur d’où proviennent les données doit être autorisée par écrit par le pêcheur et le MPO.

Exception : L’accès aux données de journaux de bord électroniques est autorisé lorsque requis par une personne responsable du support technique ou une personne travaillant sous sa supervision dans le but de diagnostiquer et résoudre des problèmes matériels ou logiciels relatifs à l’application cliente JBE.

19.1 Sécurité de l’application

L’accès à l’application cliente JBE devra être protégé par un mot de passe ou tout autre moyen reconnu permettant d’en limiter l’utilisation seulement au pêcheur ou aux personnes que le pêcheur a autorisé à effectuer le support technique. Cette limitation d’accès doit obligatoirement être gérée par l’application elle-même. L’utilisation d’une authentification au niveau du système d’exploitation n’est pas suffisante.

La clé JBE conservée dans l’application cliente JBE ne devra être visible par personne après qu’elle ait été enregistrée. Elle pourra être remplacée par une nouvelle mais ne sera jamais accessible en consultation.

La transmission d’informations sensibles ou protégées doit obligatoirement se faire au moyen d’un lien sécurisé (ex. : HTTPS).

Durant une transmission satellite entre le bateau et une infrastructure terrestre, le cryptage de certains éléments de données spécifiques est autorisé en remplacement de l’utilisation d’un lien sécurisé. Les éléments qui doivent être cryptés seront identifiés dans le dictionnaire de données XML.

19.2 Sécurité des données

L’accès aux données de journaux de bord devra être protégé par un mot de passe ou tout autre moyen reconnu permettant d’en limiter l’accès seulement au pêcheur et/ou aux personnes que le pêcheur a autorisé à effectuer le support technique.

La chaîne de traçabilité (chain of custody) des données ne doit pas pouvoir être mise en doute. Pour les cas de cour, le titulaire des droits de l’application cliente JBE devra être en mesure d’expliquer le fonctionnement de son application, spécialement concernant la gestion des données. Cela inclue le convertisseur, si applicable.

20. Support technique

Le titulaire des droits de l’application cliente JBE devra être en mesure de fournir le support technique dans les mêmes langues que celles disponibles dans son application. Le support technique devra inclure le support lors de l’installation du produit ainsi que lors de son utilisation.

En cas de problème avec l’application (bogue), le titulaire des droits de l’application cliente JBE devra pouvoir apporter les correctifs dans les plus brefs délais. En fonction de la sévérité du problème, le MPO pourrait contacter le titulaire des droits et fixer une limite à la période allouée pour faire la correction.

Le technicien devra être la seule personne autorisée à manipuler les données de l’application de journal de bord électronique (ajouter des données, modifier des données, copier des données, détruire des données) directement à partir du système d’exploitation ou à partir d’un logiciel tiers mais cela, toujours avec l’accord du pêcheur.

21. Guide de l’usager

La section 21 « Guide de l’usager » ne s’applique que si l’utilisateur n’est pas un fournisseur de service.

L’application cliente JBE doit disposer d’un guide expliquant les diverses fonctionnalités de l’application cliente JBE ainsi que les différentes étapes à réaliser pour produire un journal de bord électronique et le transmettre au MPO.

Le titulaire des droits de l’application cliente JBE devra être en mesure de fournir un guide d’usager de son application dans les mêmes langues que celles disponibles dans son application.

22. Authenticité et intégrité

En soumettant une lettre d’intérêt pour le développement d’une application cliente JBE, le titulaire des droits de l’application accepte (si requis pour un cas de cour et sans frais) de fournir la preuve qui décrit le fonctionnement de l’application et qui explique comment on s’assure que l’information transmise au MPO en utilisant l’application reflète précisément ce qui a été enregistré par l’usager.

Cette preuve peut être fournie par la déposition d’un témoin en cour ou peut prendre la forme d’un affidavit qui satisfait les exigences de la Loi sur la preuve au Canada ou autres lois pertinentes. Le titulaire des droits de l’application devra aussi être en mesure de fournir des explications détaillées concernant toute transformation ou altération des données depuis la fermeture des groupes de données jusqu’à la transmission de ces données au MPO. Cela inclue le convertisseur de données, si applicable.

23. Déclaration d’avis de confidentialité

La section 23 « Déclaration d’avis de confidentialité » ne s’applique que si l’utilisateur n’est pas un fournisseur de services.

Le texte de la déclaration d’avis de confidentialité peut être trouvé à l’Annexe C : Texte de la déclaration d’avis de confidentialité.

L’application cliente JBE devra afficher le texte de la déclaration d’avis de confidentialité lors du démarrage de l’application et y ajouter une case à cocher intitulée « Ne plus afficher ». Si l’option « Ne plus afficher » est cochée par l’utilisateur, l’application cliente JBE ne devra pas afficher le texte lors des démarrages subséquents.

Si une mise à jour du texte survenait ultérieurement, le nouveau texte devra s’afficher et la case à cocher « Ne plus afficher » sera de nouveau disponible.

24. Prérequis

Les prérequis à l’installation et/ou à l’utilisation de l’application cliente JBE devraient être clairement définis. Les prérequis décrivent l’environnement matériel et logiciel minimal pour que l’application puisse fonctionner correctement.

25. Recommandations aux développeurs d’applications cliente JBE

Les recommandations suivantes ne seront pas évaluées lors du processus de qualification. Cependant, une attention plus particulière devrait être apportée à ces recommandations lors du développement des applications clientes JBE.

Tables de codes restreintes : Certaines tables de codes sont assez volumineuses. L’utilisateur devrait pouvoir en restreindre le contenu en fonction de ses besoins lorsqu’il configure son application cliente JBE. La table des ports par exemple, contient environ 4000 ports de pêche alors que le pêcheur en utilise généralement moins de trois. Il serait donc intéressant de limiter la liste aux items que l’utilisateur utilise fréquemment. L’utilisateur devrait par contre toujours avoir la possibilité d’ajouter des items à sa liste restreinte à partir de la liste complète. Les tables des zones de pêche, des espèces, des engins de pêche, des communautés, etc. constituent de bons exemples.

Architecture logicielle de l’application cliente JBE : L’architecture logicielle de l’application cliente JBE doit être clairement définie au tout début du développement de manière à s’assurer que les diverses contraintes liés au fonctionnement du système soient prises en compte. Par exemple, le pêcheur doit pouvoir saisir ses données de journal de bord en tout temps. Par contre, il ne dispose pas nécessairement d’un lien de communication externe opérationnel durant son voyage de pêche. Un autre exemple est la facilité avec laquelle une mise à jour sera déployée ou encore la façon dont les groupes de données seront fermés.

Du fait que les besoins en terme de langue peuvent varier entre les régions, et dans le temps, il est recommandé que les développeurs d’applications conçoivent leurs applications de manière à ce qu’elles soient facilement adaptables à une clientèle francophone et/ou anglophone.

Architecture physique de l’application cliente JBE : L’architecture physique doit aussi être clairement définie au tout début du développement. Les bateaux de pêche ne disposent pas tous d’un emplacement idéal pour du matériel informatique. Certains bateaux de pêche ne disposent même pas d’une cabine fermée à l’abri des intempéries.

Certains problèmes potentiels doivent aussi être pris en compte comme par exemple, le mauvais fonctionnement d’un équipement (GPS, connectivité Internet, imprimante, support protégé pour copie de sécurité, etc.).

Ergonomie : L’application cliente JBE devrait préférablement fonctionner en mode tactile et disposer de boutons assez gros pour être facilement accessible. L’interface doit demeurer claire et facile d’utilisation. La police de caractère, la taille des caractères et les couleurs devraient être choisis judicieusement.

Profil (valeurs par défaut) : L’utilisateur devrait pouvoir configurer son application cliente JBE pour définir plusieurs valeurs qui seront utilisées comme valeurs par défaut. L’utilisateur devra cependant toujours avoir la possibilité de modifier une valeur ayant été initialisée à partir d’une valeur par défaut.

Démonstrateur (module d’essai) : L’application cliente JBE devrait disposer d’un volet d’essai de manière à permettre à l’utilisateur d’essayer le logiciel avant qu’il l’utilise en mode réel. Les données d’essais ne devront jamais être emmagasinées parmi les données réelles.

Unités de mesure : L’application cliente JBE peut offrir la possibilité de saisir les données selon une unité de mesure différente de celle spécifiée dans le dictionnaire de données. Par exemple, certains utilisateurs sont plus familiers avec le système impérial qu’avec le système métrique. L’application cliente JBE pourrait offrir la possibilité de saisir les quantités en livres mais tous les poids inscrits dans le fichier XML devront être enregistrés en kilogrammes. De même, les dates/heures du fichier XML doivent être enregistrées en date/heure UTC (Temps Universel Coordonné) dans le fichier XML mais l’application pourrait offrir la possibilité de travailler en dates/heures locales. 

Si un élément de donnée est saisi en utilisant une unité différente de celle identifiée dans le dictionnaire de données, il est primordial que la valeur de la donnée soit inscrite dans le fichier XML en respectant l’unité de mesure demandée dans le dictionnaire de données.

Copie de sécurité des données : Une procédure de prise de copie de sécurité régulière et de récupération devrait être mise en place pour parer la perte de données due à un mauvais fonctionnement logiciel ou matériel (ex. : problème technique, vol, feu, perte du navire, etc.).

Extractions : L’application cliente JBE pourrait générer certaines extractions de données comme par exemple, un sommaire des données saisies, un rapport des transmissions, etc.

Mise à jour de l’application cliente JBE : Si la mise à jour nécessite une installation ou une mise à jour locale sur le poste de l’utilisateur, le programme d’installation devrait être disponible via internet. L’application cliente JBE devrait aviser l’utilisateur lorsqu’une mise à jour est disponible. L’utilisateur devrait ensuite pouvoir autoriser l’installation de la mise à jour. 

Validité d’une coordonnée : Par expérience, les systèmes de GPS retournent parfois des valeurs erronées. La mise en place d’un algorithme de vérification des positions retournées par le GPS pourrait permettre de valider la justesse des valeurs retournée. Par exemple, au lieu de lire une seule coordonnée, l’application cliente JBE pourrait effectuer trois lectures et évaluer les trois résultats les uns par rapport aux autres.

Exemple :

Validité d’une coordonnée:

• La coordonnée doit se situer dans les limites définies dans le dictionnaire de données et/ou dans la fiche technique. Si elle est en dehors des limites, la coordonnée est invalide.
• La lecture du GPS retourne une latitude ET une longitude. Si ce n’est pas le cas, la coordonnée est invalide
• La lecture du GPS ne doit pas retourner d’erreur. Si une erreur est détectée (ex. : GPS non branché), la coordonnée est invalide.
• Si la coordonnée est distante de plus d’une minute des coordonnées lues précédemment parmi les trois lectures, la coordonnée est invalide.

Les 3 coordonnées retournées doivent être valides (selon les règles édictées ci-haut).

• Si les trois positions sont valides, seule la première sera retenue et utilisée pour compléter la coordonnée demandée (latitude et longitude).
• Si au moins une des trois positions est invalide, un message d’erreur s’affiche et aucune lecture n’est retenue.

Cette méthode est un exemple de processus qui permet de valider de manière minimale la qualité des coordonnées retournées par le GPS.

26. Glossaire

Application cliente JBE : Groupe complet de logiciels et de matériel utilisé pour la saisie, l’enregistrement, le traitement et la transmission au MPO des données de journaux de bord électroniques. L’application cliente JBE inclut toutes infrastructures intermédiaires utilisées par l’application cliente JBE qui ne sont pas détenues par le MPO.

Base de données du pêcheur : Base de données (ou partie d’une base de données) qui n’est pas détenue par le MPO et qui est utilisée pour conserver les informations fournies par le pêcheur.

Développeur : Personne ou groupe de personnes qui crée ou modifie une application cliente JBE.

Dictionnaire de données : Le dictionnaire de données contient la description détaillée de chacun des éléments d’information qui composent les fichiers XML des journaux de bord électroniques.

Élément de données: Élément d’information demandé par le MPO.

Fiche technique : Document technique destiné aux développeurs d’application cliente JBE. Ce document énonce certaines règles fonctionnelles qui devront être respectées lors du développement des applications clientes JBE en fonction de chaque formulaire. La fiche technique est constituée d’une liste de règles générales relatives à un formulaire et de règles plus particulières définies en fonction des flottes qui utilisent le formulaire.

Flotte : Ensemble des pêcheurs effectuant une pêche.

Formulaire : Structure du fichier XML qui sera utilisé pour transférer les données de journaux de bord électroniques au MPO. Les formulaires contiennent la liste des noeuds XML et des éléments de données exigés par une région pour une certaine catégorie d’engins de pêche.

Fournisseur de service : Entreprise disposant d’infrastructures sur lesquels réside certaines composantes (ou toutes les composantes) d’une application cliente JBE qualifiée par le MPO. Cette entreprise est mandatée par le pêcheur afin de se charger de certaines tâches comme la réception et/ou la saisie des données de journaux de bord, la vérification de ces données, la conversion des données, la transmission des données au MPO, etc. Il s’agit d’un intermédiaire entre le pêcheur et le MPO.

Groupe de données : Ensemble de données indissociable formé par le regroupement de un ou plusieurs noeuds XML. (Voir la section 3.6 « Les groupes de données »)

Guide de l’usager : Document, destiné aux utilisateurs d’une application cliente JBE, expliquant le fonctionnement de l’application.

Initialiser : Attribuer une valeur à une donnée

Instructions: Les instructions sont des explications fournies par le titulaire des droits de l’application cliente JBE et destinées aux utilisateurs de son logiciel. Elles apportent des précisions sur la façon de compléter chaque formulaire de journal de bord électronique en fonction de ce qui est demandé par le MPO.

JBE : Journaux de bord électronique. En anglais ELOG (Electronic logbooks).

Journal de bord : Registre exigé des pêcheurs par le MPO, détaillant les activités effectuées lors d’un voyage de pêche.

Journal de bord papier : Journal de bord imprimé sur du papier et sur lequel les informations demandées ont été ou seront inscrites à la main.

Journal de bord électronique : Journal de bord rempli à partir d’un logiciel spécialisé.

Message d’avertissement : Message informatif destiné à l’utilisateur. Ces messages visent à porter une situation particulière à l’attention de l’utilisateur. Suite à l’affichage d’un message de ce type, le processus en cours ne sera pas arrêté.

Message d’erreur : Message destiné à l’utilisateur de l’application cliente JBE pour l’aviser qu’une situation anormale a été détectée. Suite à l’affichage d’un message de ce type, le processus en cours sera arrêté.

Norme : Une norme est un ensemble de spécifications techniques. Elle est élaborée en recherchant un consensus parmi les intervenants intéressés (Associations de pêcheurs, représentants du MPO, Développeurs informatiques, etc.).

Pêche : Pêche d’une espèce spécifique (ou d’un groupe d’espèces) effectuée en utilisant un engin de pêche(ou un groupe d’engins de pêche) dans une zone de pêche(ou dans un groupe de zones de pêche).

Qualification des applications clientes JBE : Processus visant à vérifier la conformité d’une version précise d’une application client JBE par rapport aux spécifications demandées. Une application cliente JBE non qualifié ne pourra pas transmettre ses données au MPO.

Région : Région administrative du MPO, soit :

Support technique : Personne ou entreprise mandatée par le pêcheur ou par le fournisseur de service afin d’aider les utilisateurs à résoudre les problèmes d’installation et/ou de fonctionnement de l’application cliente JBE.

Tables de codes : Séries de codes utilisées par l’application cliente JBE. Généralement, une table de codes inclura plusieurs colonnes et plusieurs lignes. Chaque ligne contient un identifiant unique (le code) et quelques colonnes qui réfèrent à des attributs du code (ex. : Description française, description anglaise, etc.). Exemple de tables de codes : Table des espèces, Table des engins de pêche, Table des communautés, Table des régions, etc.

Titulaire des droits de l’application cliente JBE : Personne ou entité légale propriétaire de l’application cliente JBE.

Utilisateur : Personne qui saisit l’information du journal de bord. Il peut s’agir du pêcheur lui-même ou de personnes qu’il autorise à faire la saisie des données de journaux de bord en son nom (une connaissance ou un fournisseur de service). Durant la phase 1, les pêcheurs seront les seuls utilisateurs des applications clients JBE. Dans la phase 2, les pêcheurs et les fournisseurs de services seront des utilisateurs.

Annexe A : Fermeture d’un groupe de données (pour information)

A.1 Schémas

Dans les schémas suivants :

1. Le schéma se lit du haut vers le bas
2. La couleur de fond rosée indique qu’une intervention de l’utilisateur est requise
3. La couleur de fond bleue indique un processus automatisé
4. La couleur de fond verte indique l’intention de l’utilisateur
5. Les messages inscrits en bleu sont des messages informatifs destinés à l’utilisateur
6. Les messages inscrits en rouge sont des messages d’erreur indiquant à l’utilisateur qu’une opération qu’il désire effectuer s’est terminée anormalement.
7. Les cercles bleus indiquent le début et la fin d’un processus
8. Lorsqu’on parle de groupe de données, le groupe de données inclut tous les éléments de données faisant partie de ce groupe
9. Lorsqu’on parle de pseudo-XML, on parle d’un fichier XML « temporaire » ne contenant que le groupe de données lui-même et ses parents. Ce pseudo-XML n’est utilisé que pour tester la validité d’un fichier XML généré à partir du groupe de données par rapport au XSD.

Description pour le diagramme : Processus de création ou de modification d'un groupe de données vs le statut du groupe de données

Description pour le diagramme : Processus de destruction d'un groupe de données vs le statut du groupe de données

Description pour le diagramme : Processus de transmission des groupes fermés

Annexe B : Éléments de données non modifiables par l’utilisateur

Les éléments de données identifiés dans le tableau suivant ne sont pas modifiables par l’utilisateur :

Annexe C : Texte de la déclaration d’avis de confidentialité et attestation du pêcheur

ÉNONCÉ DE CONFIDENTIALITÉ

Les renseignements que vous fournissez en utilisant l’application cliente de journaux de bord électroniques sont recueillis en vertu de la Loi sur les pêches et du Règlement de pêche (dispositions générales) dans le but d’administrer la pêche commerciale relevant de la compétence de Pêches et Océans Canada (MPO). Ces renseignements peuvent également être utilisés aux fins de vérification de la conformité, de planification ou de gestion des programmes, de production de rapports, de sécurité ou de sûreté, de vérification, d’évaluation, de statistiques, de recherche, d’élaboration de politiques, d’administration ou application d’une loi, de détection, de prévention ou de répression d’un crime, ainsi que d’enquêtes. En vertu de la Loi sur la protection des renseignements personnels, vous avez le droit de corriger vos renseignements personnels, d’y accéder et de les protéger. Vous avez aussi le droit de déposer une plainte auprès du commissaire à la protection de la vie privée du Canada au sujet du traitement de vos renseignements. Les renseignements personnels recueillis par l’application cliente de journaux de bord électroniques sont décrits dans le fichier de renseignements personnels (FRP) MPO PPU 410. Il est possible d’y accéder et d’en vérifier l’exactitude. Pour obtenir plus de renseignements, consultez le site d’Info Source.

ATTESTATION DU PÊCHEUR

Les renseignements recueillis dans ce formulaire de journal de bord électronique sont assujettis à la Loi sur l'accès à l'information (L.R.C., 1985, ch. A-1) et à la Loi sur la protection des renseignements personnels (L.R.C., 1985, ch. P-21) et seront traités en conséquence.

En soumettant ce formulaire de journal de bord électronique au MPO, j'atteste ce qui suit :

Je déclare être le titulaire du permis ou l'exploitant de substitut nommé pour le permis fourni dans ce formulaire de journal de bord électronique. J'atteste que les informations fournies sont vraies, exactes et complètes. Je comprends que les renseignements que je fournis au MPO sont recueillis dans le cadre des conditions de permis émises en vertu du Règlement de pêche (dispositions générales) (DORS/93-53). Je comprends que faire une déclaration fausse ou trompeuse, oralement ou par écrit, constitue une infraction à la Loi sur les pêches (L.R.C., 1985, ch. F-14).