Administration électronique - CERFA au format PDF - Tout le monde peut-il les lire ?

Bonjour,

J’ai constaté récemment que j’étais dans l’impossibilité d’utiliser un formulaire CERFA au format PDF.
Pourtant tout indique dans la définition de ce format que je peux le consulter quelque soit la plateforme que j’utilise.

Aucun de mes lecteurs PDF libres n’est en mesure d’ouvrir ce CERFA.pdf.
De plus, le message d’erreur est explicite: seul le lecteur PDF de la société Adobe peut lire ce document.

Je ne tire aucune conclusion ici moi-même. Je cherche juste l’interlocuteur qui pourra convaincre la bonne personne qu’il y a une anomalie.

Voici les références pour retrouver le document dont je parle:

Le formulaire CERFA :
https://www.formulaires.modernisation.gouv.fr/gf/cerfa_13754.do

La page où il est proposé au téléchargement:
https://www.service-public.fr/particuliers/vosdroits/R20300

Cordialement,
Xavier Pollart

Utilisateur Linux depuis 15 ans.

5 J'aime

Voici la situation actuelle, telle que je peux la voir depuis la DINSIC.

Le problème

Certains formulaires PDF permettent la saisie d’informations directement dans le fichier PDF en utilisant une technologie appelée XFA (XML Forms Architecture).

XFA pose de vrais soucis d’interopérabilité qui sont identifiés et connus depuis plusieurs années :

  • Cette technologie n’est pas normalisée. Elle ne fait pas partie de la norme ISO 32000-1:2008 qui définit le format PDF (format recommandé dans le RGI).
  • Elle est uniquement définie dans une spécification propriétaire de la société Adobe.
  • Seul le lecteur de PDF de la société Adobe, Adobe Reader, implémente l’ensemble des fonctions XFA (depuis la version 8 datant de 2006).
  • Des versions à jour d’Adobe Reader existent pour Windows, MacOS et Android, mais les autres systèmes d’exploitation comme GNU/Linux ou iOS en sont privés.
  • Les solutions libres (toutes plateformes confondues) permettant de lire des PDF implémentent bien la norme ISO PDF, mais pas l’extension XFA propriétaire d’Adobe.

La situation actuelle

Sur les quelques milliers de formulaires accessibles en ligne depuis le site service-public.fr :

  • Un peu moins de 280 intègrent des fonctions de type XFA et ne sont donc potentiellement :
    • pas utilisable pour des usagers qui disposent de plateformes GNU/Linux ou iOS
    • pas utilisable pour des usagers disposant de plateformes Windows, MacOS, et Android, mais utilisant un lecteur PDF libre (comme par exemple celui recommandé au niveau interministériel dans le SILL)
  • Plus aucun nouveau formulaire n’est ajouté sur service-public.fr avec cette technologie propriétaire.

À l’avenir

La DILA qui gère service-public.fr s’est engagé dans un vaste programme de refonte de sa plateforme de services en lignes. Ce programme prévoit, à terme, de remplacer totalement les formulaires PDF par de vraies démarches interactives en ligne.

À ce jour, le plan de reprise de tous les formulaires PDF (en particulier ceux avec la technologie XFA) vers des démarches interactives n’est pas encore défini. C’est un travail important à coordonner avec tous les ministères concernés.

4 J'aime

C’est un problème (récurent) d’interopérabilité (cf RGI v2)
Ne serait il pas possible que l’état (1 ministère volontaire?) mette des ressources (etp des €.) sur le développement d’un Reader libre et complet.
Celui qui se trouve sur le SILL est peut etre une bonne piste ?
Sur ce type de problématiques (accès, normes, formats) la France pourrait être moteur et porter ces problématiques au niveau européen ? (dinsic directement ?)
Ce sont des points sur lesquels il faut mutualiser et ce au niveau europeen (au moins)
fa

1 J'aime

C’est (malheureusement ?) mission impossible, la spécification XFA n’étant pas ouverte. L’intérêt est de toute façon limité face à du formulaire en ligne.

Pour ce qui est des usages plus classiques du format, je n’ai pas l’impression que les lecteurs libres soient limitants.

2 J'aime

Je vous remercie vivement pour vos réponses et votre attention.

Personnellement je ne peux pas agir plus, du moins je ne pense pas.
J’espère que tout ceci sera résolu dans les meilleurs délais, comme me le laissait entendre la réponse type de support1.msp@service-public.fr

1 J'aime

Quelques discussions à ce sujet sur trollfr :

Là où le bas blaisse, c’est que si on veut juste imprimer le document pour le remplir à la main, ce n’est même pas possible non plus.

Sans aller jusqu’à la numérisation totale des démarches, il faudrait au moins proposer un PDF « pour impression » :slightly_smiling:

1 J'aime

Si la spécification XFA est propriétaire, alors il faut en créer une autre … Libre / Opensource.
Si l’idéal est les formulaires en ligne tant que de nombreuses administrations ne les mettrons pas en place, il y aura aussi un intérêt limité.

1 J'aime

Il faut aussi viser une certaine qualité dans la mise en œuvre des formulaires web. J’ai déjà été témoin de nombreux cas de dépôts de dossiers en ligne, mal pensés, où :

  • les sessions expirent trop rapidement par rapport au contenu éditorial exigé par l’administration => perte de contenu irréversible pour le quidam ;
  • les boutons de navigation web font planter la demande => perte de contenu irréversible pour le quidam ;
  • les vérifications/contraintes imposées n’envisagent que des cas naïfs et nient la complexité de situation des usagers => stress et sentiment de régression par rapport au dépôt papier ;
  • aucune api n’est disponible pour l’automatisation des dépôts … voire, quand on se trouve face à une possibilité d’un bête import csv, le service en face est tellement autiste qu’il faut avoir des compétences de geeks pour pouvoir uploader la moindre série de lignes.

Personnellement je rêve comme beaucoup de geeks de la rationalisation dans l’échange d’information (pour éviter aux documents de devoir être saisis, imprimés, signés, scannés, ressaisis, enterrés 3 mois dans le jardin et recyclés comme allume feu avant que l’info soit traitée), mais pitié il faut vraiment insister sur la qualité…

2 J'aime

Cela reflète assez bien les conséquences (in fine) qu’engendrent les solutions verrouillées, ici on a un mécanisme qui a perduré par manque de réflexion (les données publiques conditionnées par une solution et un format verrouillé?).

2 J'aime

J’apporte ici un autre témoignage, ayant développé dans ma société le pré-remplissage de CERFA de la sécurité sociale pour remboursement de frais de déplacement à partir de données d’une application de gestion de CAMSP/CMPP/SESSAD (dispensaires psycho-médicaux-sociaux) je me suis aperçu que la partie XFA des PDF n’était pas utilisable, plusieurs champs ayant le même nom (c’est comme donner le même nom à plusieurs champs dans un formulaire Web, ça ne va pas marcher). Ça marchait très bien dans Acrobat Reader si on remplit et on imprime mais si on utilise un outil d’édition de PDF comme pdftk (https://www.pdflabs.com/tools/pdftk-server/ malgré l’aspect du site c’est tout à fait libre) les données se mélangent.

De fait la partie XFA des formulaires n’est pas testé du tout et donc ne marche pas, c’est fait à la va vite en posant les masques de saisie sur les formulaires mais pas du tout pensé dans une démarche de dématérialisation. Pour notre outil nous avons du redévelopper notre propre solution de masque de saisie au dessus de PDF http://git.entrouvert.org/calebasse.git/tree/calebasse/facturation/invoice_template.py )

Aussi la norme XFA est plutôt bien comprise (l’existence de pdftk et nombreuse autre librairie le prouve) le problème c’est que la soumission par le réseau d’un formulaire PDF entre Acrobat Reader et un serveur Adobe Form Server est protégée par une clé publique de signature embarquée dans Acrobat qui n’acceptera jamais de soumettre le formulaire à une solution tierce, c’est plus que fermé, c’est verrouillé. Maintenant rien n’empêche de soumettre le PDF lui même et d’en extraire les métadonnées XFA, Acrobat ne sait bien sûr soumettre qu’avec son propre protocole, impossible de lui faire faire un simple POST du contenu du PDF sur un web-service.

2 J'aime

Je suis développeur (pro) et développeur de logiciel libre. Mais je suis également papa d’une fille atteint de troubles envahissants du développement.

Le CERFA 13788 (Formulaire de demande(s) auprès de la MDPH) qui doit servir pour tous les cas est juste imbuvable. Huit pages avec des cadres à remplir selon le besoin et trois pages juste pour les explications. Donc 99% de chance de se planter un moment ou un autre :worried:.

Je garde précieusement celui éditable dans Acrobat Reader que j’ai téléchargé il y a deux ans et qui est impossible de trouver actuellement… Plus de galères de ratures, de fôte d’ortografe, de refaire une page, de repentir, etc. En attendant une solution pérenne et libre, je trouve dommage de priver les usagers de ses facilités.

Ne pourrait-il être envisageable dans un premier temps d’avoir un format ouvert (basé sur JSON ou XML) de description formelle du CERFA, nom des champs, identifiant du champ (pour une éventuelle soumission en ligne par web service), texte d’aide au remplissage, regroupement en section, et conditions de remplissage (type, longueur du champ acceptée, champ visible uniquement si tel case coché, etc…) et de validation (ex.: valide le format des numéro de sécu ou des IBAN, ou date de naissance ou code postal, etc…). Cela permettrait à la fois de générer des formulaires en ligne ainsi que des formulaires imprimables (en ajoutant des annotations de présentations pour en obtenir une version PDF) et aussi de documentation pour d’éventuel web-service de soumission en ligne. Une sorte de co-marquage pour les CERFA.

9 J'aime

Je suis en train de mener une étude de faisabilité (DINSIC) sur un projet qui correspond exactement à ce que vous décrivez. Si vous souhaitez me faire part d’éléments complémentaires, si vous êtes intéressé pour participer à d’éventuels ateliers, ou pour nous faire part de votre expertise, je vous invite à me transmettre vos coordonnées en message privé (ainsi que toute autre personne intéressée …). Merci !

4 J'aime

L’Etat a déjà montré qu’il est capable de bien faire.
Voir le système de télédéclaration des revenus (qui s’améliore d’ailleurs d’année en année, bravo les équipes de devt): les formulaires sont clairs, le contenu est conservé de session en session, des mécanismes de suggestion de saisie sont proposés, etc.

Certes la route est longue, il est permis de rester positif

1 J'aime

Bonjour Marine,

Où en êtes-vous de votre réflexions de faisabilité avec le DINSIC ?
Nous serions tous intéressés de savoir ce qu’il en est ressorti !

Merci !

Bonjour
Concernant une description formelle qui serait obligatoire et normée, les conditions ne sont pas réunies pour mener un tel projet aujourd’hui. Nous allons cependant organiser un atelier dans les mois qui viennent pour identifier les principes, critères et outils permettant de formaliser ce que serait une démarche en ligne adaptée aux différents référentiels en usage, et aux pratiques contemporaines du web. Nous nous intéresserons en particulier aux données « récurrentes » et aux conditions de mise en œuvre du principe « Dites le nous une fois ». Lorsque nous aurons fixé une date, je ferai une annonce sur ce post si certains veulent se joindre à nous, vous êtes les bienvenus.

1 J'aime

Bonjour,
J’ai entendu cela depuis quelques temps.Tout à l’heure encore. Ce sont les dernières versions d’Adobe et les formulaires PDF créés avec Adobe.
J’ai lu avec attention tout ce fil, notamment concernant la norme XFA.
Je vais donc poser une question très très naïve. Mais les formulaires conçus avec LibreOffice fonctionnent dans quasiment tous les lecteurs pdf, tous systèmes… (pas sumatra malheureusement)
Ne serait-ce pas une première solution très simple que d’utiliser LibreOffice au lieu d’Adobe ?

Bonjour,

LibreOffice répond à quasiment toutes mes exigences de production (docs, schémas, tableaux, zones de saisies), leur export PDF (formé et modifiable) est très satisfaisant.

Avec LibreOffice, on peut même enregistrer le document source modifiable dans le PDF, ce qui permet d’ouvrir par la suite ce PDF pour le modifier !

1 J'aime