Plateforme d'emploi inclusif SODEB et Cabinet Finex

Le contexte

SODEB, organisation non gouvernementale, et le Cabinet Finex portent ensemble un programme d'inclusion professionnelle des personnes en situation de handicap. Sur le terrain, l'accompagnement tenait debout : ateliers, évaluation des compétences, mise en relation avec des employeurs partenaires. Ce qui manquait, c'était l'outil. Les dossiers vivaient dans des tableurs, les échanges dans des boîtes mail séparées, et personne ne pouvait dire où en était un candidat sans appeler deux personnes.

Le problème de fond n'était donc pas de fabriquer un site. Il fallait un endroit unique où un candidat dépose son profil, où un conseiller suit son parcours, et où une entreprise consulte des profils sans jamais accéder à ce qu'elle n'a pas à voir. S'ajoute une contrainte que beaucoup de projets ignorent : le handicap relève des données sensibles au sens de l'article 9 du RGPD. Le système devait être utile sans être bavard, et cette contrainte a dicté l'architecture avant le design.

Ce qui a été construit

Trois espaces, une seule base, une seule vérité.

L'espace candidat. Création de compte, profil détaillé (parcours, compétences, expérience, mobilité, disponibilité), dépôt de CV, candidature à une offre, et un suivi d'état lisible : reçu, étudié, transmis, entretien, réponse. Le candidat voit où il en est sans avoir à relancer.

L'espace conseiller. C'est le poste de travail de SODEB et du Cabinet Finex : file de dossiers, affectation à un conseiller, notes internes, étapes d'accompagnement, relances, historique des échanges. Le conseiller voit l'ensemble du dossier parce que c'est son métier, et chaque consultation est tracée.

L'espace employeur. Publication d'offres, recherche filtrée par métier, secteur, expérience et disponibilité, réception des candidatures, changement de statut. L'employeur voit les compétences et la disponibilité. Il ne voit ni diagnostic, ni détail médical, ni pièce justificative. Ce cloisonnement n'est pas un réglage que l'on oublie, il est inscrit dans le modèle de données.

En transverse : rôles et permissions, notifications par email, journal d'activité, tableau de bord de programme pour suivre l'avancement réel des parcours, et des pages d'offres publiques et indexables, pour que les opportunités sortent du seul cercle des inscrits.

Les choix techniques

Laravel, MySQL, Blade, files d'attente. J'ai écarté WordPress assez vite : un site vitrine se livre rapidement, mais dès qu'il faut des rôles fins, des règles d'accès par champ et un historique d'actions, on finit par écrire une application dans le dos du CMS. J'explique ce raisonnement plus en détail dans WordPress ou Laravel, comment choisir.

Concrètement :

• Les autorisations passent par des policies et des gates. Chaque requête vérifie qui demande quoi, et pas seulement si la personne est connectée.
• Les données sensibles sont minimisées et séparées du profil visible. Ce qui n'est pas nécessaire à une décision n'est pas collecté.
• Les CV et les pièces sont stockés hors de la racine publique, puis servis par des liens signés à durée limitée.
• Les emails partent en file d'attente, pour que l'expérience reste fluide quand le serveur d'envoi ralentit.
• La recherche s'appuie sur un index plein texte côté base, avec des filtres calculés côté serveur, jamais côté navigateur.
• Les offres publiques sont structurées en données JobPosting pour Google, avec sitemap et URLs propres.

L'accessibilité a été traitée comme une exigence de base : contrastes, navigation clavier, formulaires étiquetés, messages d'erreur explicites, structure de titres cohérente. Sur un produit destiné à des personnes en situation de handicap, une interface qui suppose une souris et une bonne vue serait une faute professionnelle. Les repères sont publics : les règles WCAG du W3C et, côté Europe, la logique du RGAA et de l'European Accessibility Act.

Sur la protection des données, je suis parti des principes de la CNIL sur le RGPD : finalité définie, minimisation, durée de conservation, accès limité et journalisé.

Le résultat

Le programme dispose aujourd'hui d'un système unique. Un dossier vit à un seul endroit. Un conseiller ouvre une fiche et lit le parcours complet au lieu de reconstituer l'histoire. Un employeur reçoit des candidatures filtrées, avec l'accord du candidat, et sans information qu'il n'a pas à manipuler. Un candidat sait où il en est.

Je ne mets pas de pourcentage ici, parce que je n'en ai pas mesuré et que je refuse d'en inventer. Ce que je peux décrire, c'est le changement de nature : on est passé d'un suivi artisanal, dépendant de la mémoire des gens, à un processus outillé, traçable et transmissible. C'est exactement ce qui manque à un programme d'insertion au moment où il change d'échelle.

Pour qui cette réalisation est utile

Si vous gérez une plateforme d'emploi, un cabinet de recrutement, un job board sectoriel, un programme d'insertion ou une fonction RH avec plusieurs parties prenantes, cette réalisation dit trois choses.

D'abord, un système à trois rôles (candidat, conseiller, employeur) ne s'improvise pas avec un formulaire et une table en base. Il se conçoit à partir des décisions que chacun doit prendre, et des informations strictement nécessaires à ces décisions.

Ensuite, quand un projet touche à des données sensibles, la conformité n'est pas une couche ajoutée à la fin. Elle se traduit dans le modèle : quels champs existent, qui peut les lire, combien de temps ils restent, et comment on prouve qui y a accédé.

Enfin, l'accessibilité et la qualité perçue ne s'opposent pas. Une interface sobre, lisible et rapide sert tout le monde, y compris un responsable recrutement pressé à Lyon, Bruxelles ou Montréal.

C'est le type de projet que je prends en charge dans le cadre de mon offre systèmes métier sur mesure, souvent en complément d'un travail de fond sur le web et la conversion.

Si votre processus vit encore dans des tableurs et des fils de mails, le plus utile est d'en parler trente minutes. Le diagnostic est gratuit et vous repartez avec une lecture claire de ce qu'il faut construire en premier.