Documentation en ligne

Référentiel simplicité

Avant propos

Il existe nombre de référentiels aux finalités différentes et dont l'utilité n'est pas à discuter (RGAA pour l’accessibilité, RGS pour la sécurité, RGI pour l’interopérabilité, RGPD pour la protection des données personnelles et DSFR pour le Système de Design de l'État).
L'objectif n'est pas de surcharger encore en exigences, mais de présenter des bonnes pratiques et des principes de simplicité avec Publik.
Comme beaucoup de référentiel, libre à chacun de se l'approprier et de l'appliquer en tout ou partie.
Nous illustrons l'approche par deux verbatim :


« Faire simple ne doit pas être compliqué. »
« Ce n'est pas parce que beaucoup est permis, qu'il faut faire n'importe quoi. »  

Généralités

Encourager et interpeller

  • Préférez une incitation plutôt qu'une injonction. Les libellés des champs des formulaires peuvent être tournés sous forme de questions explicites (hors nom, prénom...). Exemple : « Quelle taille de composteur souhaitez-vous ? » au lieu de « Taille du composteur ».
  • Personnalisez l'information à l'utilisateur dans les démarches, courriers, etc. L'information donnée à l'usager peut être personnalisée en fonction du service sollicité et de ses réponses. Il est proposé d'apporter le maximum de détails explicites lorsque cela est possible. Exemple : confirmation d'un rendez-vous avec la date et le lieu plutôt qu'un simple courriel sans précision. D'une manière générale, il n'y a pas d'étude ni de certitude que nommer l'usager dans les échanges améliore la GRU (exemple : Bonjour prénom nom) : libre à chacun de le faire.

Simplifier

  • Chassez la surabondance d'informations ou les besoins trop larges. Il est important de bien cadrer la finalité et le service à proposer.
  • Simplifiez avec les usagers, impliquez-les dans le cadre d'une amélioration continue. Les remarques et suggestions des citoyens et des agents sont utilisées pour améliorer en continu les démarches.
  • Évitez d'utiliser l'italique, le gras, les parenthèses. Ce sont parfois des artifices pour essayer de clarifier une information trop complexe et qui nuisent à l'accessibilité.

Limiter

  • Limitez. Comprendre une liste de 50 éléments est plus difficile et chronophage que comprendre une liste de 7 éléments. Dans la mesure du possible, limitez le nombre d'éléments des champs liste, nombre de pages, etc. 

Il faut trouver l'équilibre entre présenter l'exhaustivité des choix sans perdre l'usager dans un dédale de choix.

Uniquement l'essentiel à l'instant T

  • L'information donnée, comme l'information demandée, doit être proposée au moment opportun pour être percutante et appréciée. (proposez « entrée » puis « plat » puis « dessert » plutôt que « buffet » dès l'entrée dans le formulaire) 
  • Respectez le principe : l'utilisateur peut saisir uniquement les informations qu'il possède à l'instant T. Exemple : Les informations de qualification et traitement pourront être apportées dans le workflow.
  • Dans les formulaires, limitez-vous aux champs strictement nécessaires à la demande et évitez tous les champs facultatifs. 

Si un champ est nécessaire, il faut trouver la condition pour laquelle il doit être affiché et le rendre éventuellement obligatoire. 
Exemple : il n'est pas nécessaire de demander l'adresse postale ou le numéro de téléphone si vous ne les utilisez pas.

Tu ne répéteras pas, Tu ne répéteras pas, Tu ne répéteras pas

  • Évitez de dupliquer la même démarche chaque année, et préférez une générique. Exemple : « S'inscrire à la fête de la mirabelle 2022 » « S'inscrire à la fête de la mirabelle 2023 » « S'inscrire à la fête de la mirabelle 2024 » « S'inscrire à la fête de la mirabelle 2038 »... vous pouvez proposer une démarche « S'inscrire à la fête de la mirabelle ».
  • Ne répétez pas des champs dans le formulaire : si vous répétez systématiquement un champ pour différentes situations, il vaut mieux en utiliser un seul et améliorer la condition d'affichage.

Sois hOmogènE

  • Soyez constant et homogène dans votre approche et votre charte éditoriale. Exemple : Commencez les titres des formulaires par un verbe d'action. Utilisez le même libellé et identifiant pour le même champ sur tous les formulaires (exemple : courriel).
  • S'adresser à l'usager de la même manière d'un formulaire à un autre. Exemple : à la première personne « j'ai / Mon » , ou à la 2e personne : « Vous / Votre ».
  • Classez et rangez
  • Respectez des conventions de nommage.
  • Dans le cas de plusieurs rédacteurs de démarches, il pourra être utile de rédiger une charte éditoriale du portail des démarches.

 « Merdique ton français ne doit pas être » versus Simplifier le langage administratif

  • Faites des phrases à la forme active (contrairement à la forme passive), courtes et positives.
  • Utilisez des termes lisibles et compréhensibles. Vous pouvez vous inspirer du lexique administratif ou chercher le bon vocabulaire avec les utilisateurs.
  • Utilisez un langage clair : les explications sont sans ambiguïté, les mots utilisés sont accessibles à tous et ne posent pas de problème de compréhension ;
  • Quand vous utilisez un sigle ou un acronyme pour la première fois, développez-le pour en donner la signification. Exemple: « Vous avez rendez-vous avec un Référent Entretien d'Orientation (ROP) à la Maison De la Solidarité (MDS)... »  plutôt que « Vous avez rendez-vous avec un ROP à la MDS ».

Rangement et convention de nommages

Cette section décrit les bonnes pratiques du « low code » de l'écosystème Publik.
Cela peut paraître anodin, mais ranger et bien nommer les éléments participent à la simplicité, la cohérence et la maintenabilité d'un écosystème. 
Si vous travaillez seul, c'est de la rigueur ; si vous travaillez à plusieurs, c'est une nécessité : une charte de nommage.

Catégoriser

  • Utilisez et rangez dans des catégories. Les catégories sont utiles pour ranger des éléments (formulaire, workflow, agenda, fiche, etc.) en back-office, mais également à donner des accès en front office pour les formulaires.
  • Dans l'idéal, les catégories doivent apporter une cohérence entre les catégories de formulaires, de workflow, d'agendas. Exemple: «État-civil » pour les formulaires, les workflows et les agendas

Respecter la CaSsE

  • Soyez cohérent sur la casse. Exemple : commencez toujours pas une majuscule, ou jamais.
  • Mettez en minuscule systématiquement les identifiants des champs (exemple : commune, id_procedure, date_naissance) et soyez cohérent dans les identifiants composés. Exemple : nom_parent, prenom_parent et pas nomParent, Prenom_parent.

Préfixer

  • Généralisez l'utilisation de préfixes pour mieux identifier et ranger. Exemple : État-civil - Responsable,  État-civil - Agent. Les préfixes peuvent être utilisés sur les fiches, workflows, rôles, variables, agendas, modèles de mail.
  • Préfixez les agendas par le lieu. Exemple : Mairie centrale - CNI & passeports ; Mairie centrale - dépôts de dossiers ; Mairie annexe - CNI & passeports ; Mairie annexe - dépôts de dossiers.
  • Préfixez les sources de données. Exemple : API entreprise - entreprise ; API entreprise - Établissement.
  • Préfixez avec la même syntaxe. Exemple toujours : [préfixe] xxx ; ou toujours : Préfixe - xxx.
  • Préfixez le rôle par le nom de la commune et le nom du service.

Nommer

Les formulaires

  • Un titre de formulaire commence toujours par un verbe d'action, pour être explicite sur la finalité de la démarche et sur l’action attendue par l’usager. Exemple : « Consultation citoyenne » est un titre à vague. Vous pouvez préciser la finalité « Participer à la consultation citoyenne », « Proposer une consultation citoyenne », etc.
  • Un formulaire et son workflow associé portent le même nom si le workflow est dédié à ce formulaire.

Les statuts

  • Utilisez des noms simples pour les statuts : « Traité » et pas « Dossier Traité ». « Transmis » et pas « Votre demande a été transmise à nos services ».  Les noms de statuts longs sont plus difficiles à lire dans les pages de traitement, filtres, conditions, etc. Mais le statut peut s'accompagner d'un message dans l'historique : « Votre demande a bien été transmise à nos services. »
  • Soyez cohérent sur le nom des statuts sur tous les workflows. Exemple : ne pas utiliser « En cours ». ou « En cours de traitement » alternativement.
  • Le nom des statuts doit être un qualificatif de la demande et pas un verbe à l'infinitif. Exemple : « Traité » et pas « Traiter ».

Les workfows

  • Les libellés de boutons (sauts manuels) commencent par un verbe d'action. Éventuellement ils peuvent commencer par un pictogramme. Exemple : « ✅ Accepter la demande ».
  • Les libellés de boutons explicitent la suite du traitement. Évitez « Continuer » ou « Valider ».

Les rôles et les fonctions

  • Les noms de fonctions et de rôles peuvent être au pluriel ou au singulier. Faites un choix et appliquez-le.
  • Évitez les sigles. Quand vous utilisez un sigle ou un acronyme pour la première fois, développez-le pour en donner la signification. Exemple: « Vous avez rendez-vous avec un Référent entretien d'orientation (ROP) à la Maison de la Solidarité (MDS)...  » plutôt que « Vous avez rendez-vous avec un ROP à la MDS ».

Les blocs de champs

  • Les blocs peuvent être au pluriel ou au singulier. Faites un choix et appliquez-le.

Les modèles de fiches

  • Les modèles de fiches ont des noms au pluriel ou au singulier. Faites un choix et appliquez-le.au plurielsingulier, parce qu'ils vont contenir plusieurs fiches car ce sont des modèles pour une structure de données. Exemple : un senior, un enfant, une famille.

Les identifiants

  • N'utilisez pas les mots form ou var dans le nom des identifiants.

Spécificités

L'écosystème Publik propose des fonctionnalités toujours plus nombreuses : formulaires, workflows, agendas, blocs de champs, fiches, etc.
L'objectif de ce paragraphe n'est pas de reprendre les conventions de nommage décrites ou convenues préalablement mais de donner des bonnes pratiques sur les fonctionnalités.

Des formulaires

  • Le titre des formulaires est affiché à l'usager, il doit être compréhensible par l'usager.
  • Le titre doit expliquer la finalité de la démarche.
  • La première page du formulaire doit expliquer succinctement mais clairement le contexte de la démarche, parce que le référencement des démarches fait que l'usager peut arriver directement sur la démarche. Éventuellement ce texte de présentation peut être marqué par la classe pk-information.
  • Le formulaire doit être clair et permettre à l’usager de se repérer facilement dans les différentes pages à remplir.
  • S'il y a plusieurs collectivités, l'émetteur de la démarche doit être indiqué sur la première page du formulaire.
  • Le plus souvent possible, activez le code de suivi car il permet de retrouver une démarche sans compte et désactivez la page de confirmation.
  • Positionnez les champs toujours dans le même ordre. Exemple : prénom puis nom. Un prénom est, étymologiquement, AVANT un nom.
  • Trouvez l'équilibre entre chaque page, évitez les pages trop longues et évitez de démultiplier de nombreuses pages trop courtes. 
  • Évitez les champs non obligatoires. C'est peut être que le champ n'est pas essentiel. Si un champ est nécessaire, il faut trouver la condition pour laquelle il doit être affiché et le rendre obligatoire.
  • Privilégiez les champs « Liste » au champs « Texte » pour le principe de « statistic by design » et « privacy by design ».
  • Les champs « Liste » ont des éléments courts, sans condition. Exemple de liste à éviter : « je suis d'accord et souhaite une livraison à domicile », « je suis d'accord et souhaite retirer ma carte à la mairie ».
  • Dans un champ de type « Fichier », gérez la taille des fichiers, ou en sélectionnant « Réduire automatiquement la taille des images », ou en indiquant la « Taille maximale du fichier ».
  • Si des limitations sont posées, contrôlez-les avec des conditions. Exemple : s'il y a une limite à 60 personnes, vous pouvez ajouter une condition de sortie de page.
  • Proposez les pages identifications (prénom, nom) en fin du formulaire, si ces informations ne conditionnent pas la démarche. Les premiers éléments du formulaire doivent être ceux qui expliquent ou mettent le plus en valeur la finalité de la démarche. La page d'identification peut être présentée en début, si elle conditionne la suite du formulaire. Exemple : pour demander un composteur, la première question pourrait porter sur la taille du composteur, la situation du demandeur, plutôt que sur l'identification du demandeur. Dans la logique des sites e-commerce, le produit ou service est mis plus en avant que l'identification de la personne sauf si l'identification de la personne définit le produit/service.  
  • Préremplissez les champs : quand cela est possible préremplissez les champs, l'utilisateur n'aura qu'à les vérifier.
  • Vérifiez les champs : ajoutez systématiquement une règle de validation dès que cela est possible.
  • Dans les champs « Liste », ne laissez pas une valeur par défaut. L'utilisateur doit choisir explicitement une valeur. Exemple. indiquer en remarque --- Sélectionnez ---.

Des variables

  • Utilisez les variables définissant les URL des briques : {{ passerelle_url }}, {{ agendas_url }}, etc., plutôt que les URL en dur.  
  • Indiquez systématiquement un identifiant pour chaque champ.

Des rôles et fonctions

  • Utilisez toujours les fonctions dans les workflows : n'utiliser pas les rôles sauf dans l’action « liaison fonction-rôle».
  • Ne configurez jamais d'adresse électronique personnelle dans les workflows.
  • Optimisez la gestion des rôles en utilisant les options avancées et les mécanismes d'héritage : « Contient les permissions des rôles », « Est géré par le(s) rôle(s) ».

Des workflows

  • Minimisez le nombre de statuts. 20 statuts c'est déjà beaucoup.
  • Utilisez les variables autant que possible de manière à pouvoir mutualiser au maximum les workflows.
  • Ne dupliquez pas un statut pour une simple condition avec les mêmes actions, mais préférez un unique statut. Exemple : « Transféré au service A », « Transféré au service B », ...« Transféré au service Z » peut être fait avec un statut « Transféré » et une donnée de traitement. Cela évite les workflows complexes et de reproduire l'organigramme.

Des statuts

  • Déterminez le code couleur pour les statuts et utilisez-le systèmatiquement. Exemple : vert = nouveau ; bleu = en cours ; rouge = rejeté ; gris = terminé ; blanc = masqué à l'usager, jaune = affectation, noir = erreur.
  • Soyez le plus transparent possible dans vos workflows. Ne cachez à l'usager que les statuts qui ne lui apportent pas d'informations utiles.

Des fiches

  • Renseignez un gabarit générique afin que la fiche puisse être utilisée en source de données, même si vous prévoyez des vues personnalisées utilisées comme sources de données.

Des modèles de courriel

  • Harmonisez les sujets des courriels en précisant le statut, et le numéro de la demande. Exemple : {{ form_name }} - n° {{form_number}} {{form_status}}.
  • Rappelez à l'usager comment retrouver sa demande : lien, code de suivi. Dans les courriels vous pouvez utiliser la syntaxe suivante: 
    {% if  form_user %}
    Vous pouvez consulter votre demande sur {{ form_url }}.
    {% else %}
    Vous pouvez consulter votre demande sur {{ site_url }} avec le code de suivi {{form_tracking_code}}.
    {% endif %}
  • Utilisez les variables autant que possible ({{ form_name }}, {{ form_details }}...) de manière à pouvoir mutualiser au maximum les modèles.
  • Harmonisez les signatures des courriels.
  • Évitez les images dans les courriels car vous augmentez le risque d'être considéré en SPAM, ce n'est pas accessible, cela charge les courriels inutilement et les lecteurs n'affichent pas les images systématiquement (Adieu les beaux templates de courriel !).

Des conditions

  • Rassemblez les champs avec une même condition dans une même page, plutôt que des conditions sur tous les champs.
  • Écrivez les conditions en Gabarit (Django) et ne pas utiliser du Python (qui est en cours de dépréciation).

Des agendas

  • Dans les agendas de type « évènements », vous pouvez renseigner le « Gabarit d’affichage d’un événement » dans les options, pour éviter de ressaisir à chaque fois un nouveau libellé.
  • Ne mettez pas les places disponibles dans ce gabarit d’affichage sinon vous allez enregistrer et afficher dans les demandes d’inscriptions des informations de places qui seront vite obsolètes.
  • Dans les agendas de type « Rendez-vous », renseignez le nom du guichet qui pourra être présenté à l'usager. Exemple : Hôtel de Ville - Guichet 1.
  • Dans les agendas de type « Rendez-vous », utilisez dans la mesure du possible des durées de rendez-vous, qui sont des multiples entre eux. Cela permet d'éviter les « trous » dans les agendas. Exemple : 15min, 30min, 45min

Du profil utilisateur

  • Dans la mesure du possible limitez les champs du profil utilisateur au strict minimum.

Méthodologie

Publik est simple et puissant. Il offre différente façon de faire pour arriver au même résultat, en fonction de l'expérience de chacun. Certaines façons sont meilleures que d'autres, voici quelques règles et bonnes pratiques.

Pour commencer

  1. Définissez la finalité du dispositif : la finalité est l'expression de la raison d'être du service, éventuellement de la valeur ajoutée offerte pour l'usager ou le public ciblé. Elle doit être précise.
  2. Commencez par une version simple du formulaire. Il n'y a pas de honte à faire simple.
  3. Commencez par une version simple du workflow ou processus de traitement. Il n'y a pas de gloire à faire compliqué.
  4. Définissez les éléments de réponse (courriel, suivi dans l'historique), toujours clairs pour l'usager.
  5. Testez la version et impliquez les agents, et les usagers si possible, pour faciliter l'appropriation de tous.
  6. Toujours rester au plus près du besoin. Gérez le 80% des demandes. N'essayez pas de gérer les exceptions, mais notez les (nous y reviendrons).
  7. Travaillez l'anonymisation et la durée de conservation des démarches et des agendas avec le DPO et l'e-archiviste.

Pour améliorer ses réalisations

Rapidement vous arriverez à une première version : « une pièce à casser ».

  1. Testez et essayez de casser la « pièce à casser ».
  2. Améliorez, simplifiez.
  3. Consultez la documentation et chassez le déprécié.
  4. Utilisez les fiches.
  5. Gérez une exception à la fois.
  6. Essayez de simplifier vos démarches avec des API et données fiables.
  7. Recommencez à l'action 1.

Pour suivre le cycle de vie d'une réalisation

  1. Travaillez dans l'environnement de recette.
  2. Testez.
  3. Versionnez son travail en recette et en production. Faites une sauvegarde (version) du formulaire et workflow.
  4. Importez dans l'environnement de production.
  5. Testez. La pression monte !
  6. Publiez. Ça marche ? Se féliciter. Ça ne marche pas ? Retournez à l'action n°1.
  7. Dé-publiez, seulement quand le dispositif n'est plus nécessaire.

Pour éviter la casse

  1. Ne supprimez jamais des choses en production, sans être certain du risque encouru. Vous pouvez éventuellement masquer des champs avec des conditions.
  2. Lors des imports (formulaires, workflows, paramètres) assurez-vous qu'il n'y a pas de champs et de données de traitement supprimés par rapport à la version en production.
  3. Ne supprimez pas les formulaires, sauf les créations ou imports par erreur. Cela supprime définitivement les demandes de façon irréversible. Et il n’y a pas de raison de supprimer un formulaire utilisé. On le dé-publie et on annote éventuellement « Archive » dans son titre.

Pourchasser le déprécié

Des éléments fonctionnent encore, mais nous apportons peu d'attention à leur fonctionnement, il est donc conseillé de les remplacer dès à présent.
Chasser le déprécié c'est faire mieux et plus simple.

Conclusion

Publik s'enrichit et évolue : les bonnes pratiques aussi !
Des choses compliquées deviennent simple ? C'est bon signe. Proposez les, continuez... 

Dernière mise à jour le 19 septembre 2022 15:36 — Éditer