Une personne, un dossier : comment un département remplacé les silos par un CRM unifié

Une adolescente rejoint un programme pour jeunes. Quelques années plus tard, elle s'inscrit à un programme universitaire, puis devient donatrice. Pour l'organisation, c'est une seule et longue relation. Pour ses bases de données, elle était trois inconnues.

C’était la réalité à l’Orthodox Union, une organisation à but non lucratif qui gère plusieurs programmes sous un même toit.

L'organisation 

Les programmes de l’Orthodox Union incluent :

• NCSY pour les adolescents

• JLIC sur les campus universitaires

• Yachad pour les personnes en situation de handicap

• l'Impact Accelerator pour d'autres organismes à but non lucratif

• campagnes de plaidoyer

• programmes en Israël, entre autres

Au fil des ans, chaque département a construit son propre système, si bien que la même personne pouvait être enregistrée dans plusieurs bases de données et personne n'avait une vue complète.

Pourquoi les systèmes séparés ne fonctionnaient plus

• Pas de vue complète. Les dossiers étaient dupliqués dans plusieurs départements, de sorte que personne ne pouvait voir l’historique complet d’une personne auprès de l’organisation.

• Systèmes hérités partout. MARS, l'API Yachad, la plateforme Impact Accelerator, et une application spécifique de vérification des antécédents contenaient chacune des années de données et des flux de travail quotidiens.

• Données sensibles en jeu. Fusionner les dossiers signifiait qu'une base de données contiendrait des détails médicaux pour les programmes de jeunesse et d'inclusion. Chaque département devait toujours voir uniquement ses propres dossiers.

• Trop de travail manuel. Les approbations, confirmations, rappels et messages de remerciement étaient principalement gérés manuellement.

L’architecture : trois couches

En 2025-2026, la société de développement SoftPro a consolidé ces systèmes en une seule plateforme. Elle est organisée en trois couches :

1. Application web pour le personnel. Les départements travaillent dans leurs espaces propres, avec leurs propres écrans et règles d'accès.

2. API. Elle alimente l'application et contient la logique métier.

3. Widgets intégrables. L'inscription aux événements, les paiements et les candidatures s'exécutent sur les sites publics de l’organisation.

Au centre se trouve un dossier unique pour chaque personne et foyer. Il contient tout leur historique avec l'organisation : programmes, événements, famille, dons et communication.

Six décisions de conception qui ont fait que cela fonctionne

• Dossiers partagés, couches départementales. Chaque département ajoute ses propres données au dossier commun de la personne et du foyer. Les dossiers en double sont détectés et fusionnés.

• Migration fonctionnalité par fonctionnalité. Chaque fonctionnalité héritée a été mappée vers un nouvel emplacement, les flux de travail ont été reconstruits dans le CRM, et des outils d'importation dédiés ont transféré les données existantes.

• Confidentialité dans la couche de données. L'isolation par département filtre automatiquement chaque demande. Les règles d'accès, le suivi du consentement et les pistes d'audit ont été conçus en tenant compte des exigences HIPAA.

• Modules avec des limites claires. Chaque département a été développé dans la même base de code en même temps. Chaque zone départementale est un module séparé, vérifié automatiquement à chaque modification, ce qui réduit considérablement le risque qu’un travail sur un module n'affecte un autre.

• Widgets pour le public. Un court extrait intègre un widget sur n’importe quel site web. La connexion se fait sans mot de passe via un lien envoyé par e-mail, et les inscriptions ainsi que les paiements sont directement enregistrés dans le CRM.

• Automatisation pilotée par les événements. Une nouvelle inscription, un paiement ou une autre modification déclenche des workflows prêts à l’emploi pour les approbations, confirmations, rappels et messages de remerciement.

Pile technologique

• Backend : Node.js, Express, oRPC, Zod

• Frontend : Vue 3, TypeScript, Tailwind CSS, shadcn-vue, TanStack Query, TanStack Table, Storybook

• Données: PostgreSQL (Amazon Aurora), Prisma ORM, ClickHouse

• Widgets : Web Components (Vue)

• Authentification : Okta, Amazon Cognito

• IA : Amazon Bedrock (Claude), Google Gemini

• Cloud et déploiement : AWS, Docker, Kubernetes, Helm, GitHub Actions

• Intégrations : SendGrid, Amazon SES, Zoom, JotForm, Checkr, Congress.gov, la passerelle de paiement de l’organisation

État du projet

• Systèmes remplacés. Le CRM remplace MARS, l’API Yachad, la plateforme Impact Accelerator et une application autonome de vérification des antécédents.

• Échelle. La plateforme comprend plus de 40 modules fonctionnels couvrant la jeunesse, le campus, l’inclusion, Israël, le plaidoyer, les événements, la collecte de fonds, les paiements, le personnel et les bénévoles. Ces modules s’appuient sur plus de 480 tables de base de données, plus de 40 zones d’API et plus de 70 workflows automatisés.

• Widgets publics. Les widgets pour l’inscription aux événements, les paiements, les campagnes de plaidoyer et les candidatures de conseillers sont prêts à être intégrés.

• Vie privée intégrée. L’isolation par département s’applique à chaque requête, accompagnée du suivi du consentement et des pistes d’audit.

• Plan de déploiement. Les départements sont mis en ligne un par un, chacun étant d’abord testé par un petit groupe d’utilisateurs réels. Le déploiement complet est prévu pour la fin 2026.

Leçons pour les organisations multiservices

Le cas de l’OU montre que rassembler les données tout en conservant l’indépendance des départements peut fonctionner dans un seul système. La clé est de concevoir les deux dès le départ : un enregistrement central partagé, une isolation au niveau des données et un code modulaire. Les organisations planifiant un mouvement similaire peuvent discuter avec l’équipe SoftPro de la meilleure approche.

Conclusion

L’Orthodox Union est passée de nombreux systèmes déconnectés à une plateforme unique, où chaque personne a un seul dossier et chaque département ne voit que ce qu’il doit voir. Les workflows hérités ont été reconstruits, les sites publics alimentent directement le CRM en données et les messages de routine sont automatisés. Les départements sont transférés un par un avant un lancement complet prévu pour fin 2026.