11. RAPPORTS DE CAPTURE

Tout le sujet est semé de difficultés à la fois politiques et techniques. L’un des obstacles politiques est souligné par le fait qu’une information de capture sous format électronique, délivrée presque en temps réel, est considérée par les pêcheurs, pour plusieurs raisons, comme hautement sensible. Une des raisons de cette sensibilité est l’image que renvoie cette perspective du rapport de capture électronique, si attrayante pour les gestionnaires des pêches et les agents chargés du contrôle des pêches: leurs rapports seront soumis à un examen significativement plus minutieux.

Une autre raison, qui suscite davantage la compréhension des directeurs des pêches, est la crainte que les rapports de capture, spécialement lorsqu’ils sont couplés avec des données sur leur localisation, constituent une information protégée par le secret commercial. Le pêcheur prétend qu’il détient le droit, en dernier ressort, d’être assuré que ces renseignements ne vont pas échoir aux mains de ses concurrents.

D’un autre côté, des difficultés techniques existent, en premier lieu sur le plan international où aucun modèle de description d’une capture n’existe à un degré de précision suffisant pour satisfaire les exigences des gestionnaires des pêches. Il existe bien sûr, des standards internationaux pour l’identification des espèces de poisson (les codes FAO en trois lettres qui sont basés sur le genre biologique et la nomenclature des espèces) et des engins de pêche (codes FAO de deux et trois lettres), mais les formats pour les informations complémentaires comme la taille du poisson, l’état du produit, les méthodes de stockage, et même le poids sont souvent précisés selon des bases locales ou spécifiques.

La raison pour laquelle il existe une telle résistance à remplacer le traditionnel rapport de capture sous support papier, remis après la marée, par une méthode électronique livrant les informations presque en temps réel, c’est que les avantages sont tous en faveur de l’entité administrative qui reçoit les données. Dès lors que le pêcheur trouverait un avantage à participer à un schéma de rapport de capture sous support électronique, cette résistance serait plus susceptible de s’atténuer, voire de disparaître.

Une approche capable de changer cette équation serait l’adoption d’une norme sur un journal de bord électronique multifonctions. Il permettrait au capitaine du navire d’entrer les données de capture systématiquement et de les stocker sur le disque de l’ordinateur connecté à son terminal de communications SSN. Pour être acceptable, ce journal de bord devrait être un logiciel facile à utiliser qui faciliterait la totalité du procédé d’enregistrement conservé à bord du navire, en formatant automatiquement les messages complexes inhérents aux rapports de capture. A partir du moment où un tel programme est parfaitement intégré dans les opérations routinières effectuées par le bord, toute la question de la transmission des rapports de capture en temps réel dans des zones lointaines, est simplifiée.

Après avoir entré chaque jour les données de capture dans l’ordinateur du bord, le capitaine du navire devrait ensuite être capable, en sélectionnant divers aspects dans les données brutes qui ont été intégrées, d’envoyer à l’avance les rapports des produits à la criée du port de débarquement envisagé pour leur mise en vente; au transformateur ou à l’agent, pour leur proposer d’acheter des produits ou pour confirmer le débarquement; à l’armateur du navire. En plus de cette fonctionnalité, les données de captures seraient prêtes à être envoyées aux autorités en charge des pêches, selon un format standard de rapport de capture, et resteraient disponibles pour une interrogation du bord en cas de contrôle en mer ou au débarquement effectué par un service d’inspection compétent.

Figure 11.1 Fonctionnement du journal de bord électronique

Si l’on conçoit le journal de bord électronique comme un outil intégré, le concept de rapport de capture perd un peu de son acuité politique, pour autant que les pêcheurs professionnels soient concernés. Toutefois, afin de parvenir à cette réalisation, il est nécessaire de définir un ensemble de critères communs de saisie des données.

11.1 Champs des données du journal de bord électronique

Dans l’architecture du SSN, il semble que les éléments suivants puissent remplir les conditions pour satisfaire à un système de rapport de capture électronique:

Tableau 11.1 Eléments du rapport de capture avec le journal de bord électronique

¹ Voir annexe 4
² Voir annexe 5

11.1.1 Champs de données non obligatoires

Il apparaît qu’il n’existe aucune norme pour exprimer les champs non obligatoires, c’est à dire les méthodes de conservation, de conditionnement, le type de produit, la taille ou la qualité du poisson, ceux ci étant exprimés principalement en fonction des usages locaux. La façon qui serait probablement la plus claire pour résoudre ce problème serait de créer des tableaux simples et d’assigner à chaque élément une valeur numérique. Les tableaux suivants présentent des suggestions (non exhaustives) pour les méthodes de conservation, de conditionnement et les types de produits.

Tableau 11.2 Méthodes de conservation

Tableau 11.3 Méthodes de conditionnement

Tableau 11.4 Méthodes de travail du poisson

En raison de leur spécificité, il est possible de n’attribuer qu’un simple numéro de code aux méthodes de conditionnement et de conservation. Néanmoins, en ce qui concerne les méthodes de travail du poisson, il existe des variations possibles à partir d’un certain nombre de méthodes de base. Pour cette raison, un schéma de numérotation à trois chiffres permettant l’utilisation de sous catégories est préférable.

11.2 Format de message pour le journal de bord électronique

Il existe trop de variables qui ne sont pas basées sur des prescriptions normalisées pour proposer un format condensé pour ce type de message. Pour cette raison, le meilleur angle d’attaque serait une modification du format de message étendu élaboré dans la section 10.3. En raison des possibilités engendrées par les variables, et parce que de nombreux navires enregistreront plusieurs espèces dans un même rapport, les captures seront rapportées selon deux types de format possibles. Le premier format exprimera simplement les espèces et les quantités.

Le format ci-dessous utilisera un en-tête identique à celui du rapport de position, suivi par un champ pour les captures dans lequel les espèces sont suivies par leurs quantités correspondantes. Espèces et quantités alternent, chaque élément étant séparé par un espace jusqu’à épuisement. Leur succèdent l’engin de pêche et la zone de pêche. Avec cette approche, un navire belge appelé Ostende qui a pris 512 kilogrammes de cabillaud, 86 de turbot et 1 153 de plie au moyen d’un chalut à perche, dans la zone ICES VIId transmettrait le rapport informatique suivant à 11 heures 50 minutes, le 6 juin 1997:

//SR//TM/CAT//NA/OESTENDE//FS/BEL//TI/1150//DA/970606//CI/COD 512 TUB 86 PLA 1153//FG/VIID//GE/BT//ER

Un tel rapport serait normalement suffisant à des fins de gestion des pêcheries, mais manquerait de données précises sur la marée pour avoir un réel intérêt commercial. Le formatage d’un message incluant des informations relatives aux méthodes de conservation, de conditionnement et de travail du poisson est, de façon inhérente, plus complexe. Le principe est que l’information spécifique à un élément de capture suit immédiatement cet élément de telle sorte que le format pour les espèces capturées est le suivant:

CI/espèce[espace]quantité//CN/code//CM/code//DM/code

Cette série se répète jusqu’à ce que la liste des espèces capturées ait été épuisée, puis elle est suivie par les zones de pêche et les engins. Dans ce contexte, un navire dont le numéro d’immatriculation international est le ZYZ16845, se trouvant à environ 66 degrés de latitude nord et 37 degrés de longitude ouest, qui transmet un rapport de capture de 462 kilogrammes de lieu noir, éviscéré, étêté, glacé, conditionné en boîtes, et 891 de sole, éviscéré, non étêté, frais, conditionné en boîtes, les deux espèces pêchées avec un chalut non spécifié, transmettrait le rapport informatique suivant:

//SR//TM//CAT//RC/ZYZ16845//TI/0325//DA/971108CI/SAI
462//CN/211//CM/3//DM/4//CI/SOL
891//CN/210/CM/1//DM/4//FG/N66W037//GE/TX//ER

Plusieurs points doivent être notés concernant ces rapports. Le premier est que leur formatage manuel à bord d’un navire serait un procédé très peu fiable. Pour cette raison, ils doivent être conçus comme une sortie du logiciel du journal électronique. Le second point est que les rapports sont trop longs et comprennent trop de variables pour être traités avec seulement de petits paquets de données, comme le sont les rapports de position.

Ceci signifie que les coûts de transmission seront significativement plus élevés que ceux des rapports de position, mais peuvent être réduits en utilisant la compression des données. De plus, une fois que le format sera adopté et l’ordre des éléments formalisé, il ne restera qu’un dernier pas à faire pour le transformer en format condensé, où le coût des communications peut être minimisé. De plus, les rapports de capture sont transmis à une fréquence bien moindre que les rapports de position.