Développeur front

CAHIER DES CHARGES · REFONTE DE L’INTERFACE PRONOIA
Consultation de prestataires pour l’identité visuelle et les maquettes, sur l’ensemble du produit
Version 1 · 19 septembre 2026 · document de consultation
1. Contexte
PRONOIA est un logiciel en ligne de pilotage de la qualité, de la conformité et de la participation, destiné aux établissements et services sociaux et médico-sociaux. Le produit a été étendu à quatre verticales : accueils collectifs de mineurs, centres sociaux, espaces de vie sociale, établissements d’accueil du jeune enfant.
C’est une application web riche : plusieurs dizaines d’écrans, plusieurs profils d’utilisateurs, des écrans internes destinés aux professionnels et des écrans publics vus par des usagers, des familles et des salariés.
Un système de design existe déjà et sera fourni. Le produit est en développement actif, notamment sur les verticales et un module de régie. C’est une contrainte structurante pour l’organisation de la prestation.
2. Objet de la consultation
Nous cherchons un prestataire pour concevoir une identité visuelle et les maquettes de l’ensemble de l’interface.
Le parti pris esthétique est libre. Vous proposez ce que vous jugez juste. Le système existant vous est fourni comme point de départ documenté. Vous pouvez le faire évoluer ou proposer une rupture. Nous jugerons sur proposition.
L’objectif est une interface cohérente, lisible et soutenable sur des écrans très denses, et accessible sur les écrans publics.
3. Périmètre : tout le produit
La prestation couvre l’ensemble des espaces et des verticales.
• Espace établissement (direction et équipe). Pilotage, diagnostic bientraitance, évaluation HAS, post-évaluation, plan d’actions, prévention et gestion des risques, déclarations, preuves et références, compte et outils.
• Espaces des quatre verticales (ACM, CS, EVS, EAJ). Participation, présences, conformité des encadrants, finances, projet social, statistiques.
• Espace siège et groupe. Cockpit multi-établissements, pilotage du parc, campagnes.
• Espace d’administration. Imports de référentiels, gestion des établissements, accès de démonstration.
• Écrans publics. Connexion, réinitialisation, inscription par QR, pointage de présence par QR, déclaration par QR, enquête publique, émargement.
• Espace de découverte. La version d’essai.
Certains modules internes, par exemple le générateur de plannings de mission, sont à confirmer dans le périmètre.
4. Profils d’utilisateurs à couvrir
• Direction et équipe d’un établissement.
• Siège ou direction de groupe.
• Auditeur et évaluateur, côté cabinet.
• Administrateur.
• Usagers, familles et salariés sur les écrans publics, y compris des personnes âgées et des publics susceptibles d’utiliser une aide technique.
5. Ce que vous recevez
• La direction artistique existante : palette, typographie, échelles d’espacement, de rayons et d’ombres, langage de statut.
• Cinq composants déjà normalisés : bouton, champ, carte, tableau, statut.
• Un corpus de captures d’écran anonymisées, sur un jeu de données fictif.
• La priorité vous sera donnée sur les écrans denses, pas sur les écrans flatteurs.
6. Modèle de collaboration : deux options, préférence affichée
Point technique déterminant. Dans PRONOIA, le style n’est pas séparable de la logique. Le code mêle la mise en forme et les règles métier. On ne peut donc pas « ne retoucher que le graphisme » du code existant sans toucher au code lui-même.
Option A, retenue et préférée : vous codez seulement, sur un environnement isolé. Vous travaillez sur un bac à sable séparé, avec des données factices, sans jamais accéder au produit vivant. Vous livrez l’identité, les maquettes, et un prototype cliquable des écrans les plus denses. Nous intégrons ensuite dans le produit.
Option B, déconseillée : vous installez, c’est-à-dire vous intervenez dans le dépôt de code du produit. Écartée par défaut. Le produit est en développement actif. Une refonte menée en parallèle sur les mêmes fichiers rend les fusions impossibles et casse le produit. Recevable seulement si vous démontrez une méthode qui garantit l’absence de collision, et sous notre contrôle strict.
Pourquoi un prototype et pas seulement des images. Nos écrans clés sont très denses : l’un dépasse 2 000 lignes de code, un autre affiche plus de 250 risques. Une maquette figée sur un écran allégé s’effondre au volume réel. Un prototype sur données factices montre le comportement réel, en particulier la densité et le responsive.
7. Livrables attendus
• Un parti pris d’identité visuelle, argumenté.
• Une charte : couleurs, typographie, échelles, composants, états.
• Les maquettes haute-fidélité de chaque type d’écran, sur tous les espaces.
• Un prototype cliquable des écrans les plus denses, sur données factices, dans un environnement isolé.
• Les sources des livrables : fichiers de design et code du prototype.
• Une note d’accessibilité pour les écrans publics.
8. Contraintes de conception
• Densité. Les écrans les plus importants portent des centaines de lignes ou d’items. La conception doit tenir à ce volume, pas seulement en vitrine.
• Accessibilité RGAA sur les écrans publics. Ils sont vus par des usagers, des familles et des salariés, parfois âgés, souvent depuis un mobile. Libellés reliés aux champs, messages annoncés, navigation clavier, contrastes. Exigence, pas option.
• Langage de statut lisible en photocopie. Forme et texte d’abord, la couleur en troisième signal. Les établissements impriment.
• Impression. Une feuille d’impression existe et fait partie du périmètre.
• Responsive. Plusieurs écrans publics sont utilisés au téléphone.
• Décisions à ne pas défaire. L’aide contextuelle ne recouvre pas la barre d’action du haut. Le bouton d’aide n’apparaît que si l’écran dispose d’une fiche.
• Point de départ et rupture. La direction artistique existante vous est fournie. Si vous proposez une rupture, la reprise des écrans déjà harmonisés sera à refaire selon votre identité, à chiffrer dans votre proposition.
9. Contraintes juridiques et données
• Confidentialité. Accord de confidentialité préalable à toute remise d’éléments.
• Propriété. La cession des droits sur les livrables du prestataire est à prévoir au contrat.
• Données. Aucune donnée réelle ne vous sera fournie. Les écrans transmis sont anonymisés, sur un jeu fictif. Votre environnement de travail ne contient aucune donnée réelle.
• RGPD et dépendances. Le produit vise un hébergement de données de santé. Aucune dépendance externe non maîtrisée dans les livrables, par exemple pas de police servie depuis un service tiers.
10. Ce qui n’est pas dans le périmètre
• Le développement fonctionnel du produit.
• L’intégration finale dans le dépôt vivant, que nous portons, sauf option B retenue.
• L’hébergement et l’infrastructure.
11. Contenu attendu de votre proposition
• Votre compréhension du produit et du périmètre.
• Votre parti pris, avec une piste visuelle sur un ou deux écrans denses.
• Votre méthode de travail et le modèle choisi, A ou B.
• Le planning et les jalons.
• Le budget détaillé.
• Vos références sur des produits denses et métier, et sur l’accessibilité.
12. Critères de sélection
• Qualité et pertinence du parti pris sur les écrans denses.
• Prise en compte réelle de l’accessibilité.
• Solidité de la méthode et respect du non-accès au dépôt vivant.
• Références comparables.
• Budget et délais.