Doc-Board.

Overview

Doc-Board est une application SaaS médicale permettant aux patients et aux médecins de gérer rendez-vous, disponibilités et dossiers patients depuis une seule plateforme sécurisée.

Deux espaces distincts : côté patient — prise de rendez-vous simple et historique des consultations. Côté médecin — dashboard complet avec agenda journalier, calendrier, statistiques d'activité, gestion des disponibilités et fiches patients détaillées.

Prototype fonctionnel complet livré en une semaine. Architecture Next.js, TypeScript, Prisma avec authentification par rôle (patient / médecin).

Challenge & Problem Statement

La prise de rendez-vous médicale reste complexe, éclatée et peu intuitive. Deux profils utilisateurs aux besoins radicalement différents à réconcilier dans une seule interface.

Côté patient

• Trouver un créneau disponible rapidement
• Suivre ses prochains rendez-vous
• Avoir un historique clair des consultations

Côté médecin

• Manque d'une vue agenda simple et complète
• Difficulté à gérer ses disponibilités
• Accès insuffisant aux dossiers patients
• Manque d'informations pour le suivi médical

Solution

Pour répondre aux besoins des patients et des médecins, j’ai conçu une plateforme qui centralise l’ensemble du parcours de soins dans une interface cohérente et facile à utiliser. La solution repose sur deux espaces distincts mais construits selon les mêmes principes de simplicité et de lisibilité.

Du côté patient, la plateforme permet de consulter les disponibilités d’un médecin et de réserver un rendez-vous en quelques étapes seulement. L’expérience est volontairement linéaire, avec une interface qui met en avant les créneaux libres et les informations essentielles.

Du côté médecin, j’ai développé un tableau de bord complet regroupant les rendez-vous du jour, le calendrier complet, les statistiques d’activité et les informations professionnelles. Les médecins peuvent modifier leurs disponibilités rapidement et accéder à la fiche détaillée de chaque patient, conçue comme un mini dossier médical.

L’ensemble de l’interface a été pensé pour réduire la complexité des outils médicaux traditionnels : informations bien hiérarchisées, actions accessibles immédiatement et absence de surcharge visuelle. Cette approche a permis d’obtenir une solution simple, efficace et adaptée à des usages quotidiens.

Development

Architecture

Deux espaces distincts (patient et médecin) avec une authentification par rôle — même base de code, expériences séparées.

Stack — Next.js full-stack

• Next.js 14 + TypeScript — App Router, Server Components
• Prisma ORM + base de données relationnelle — Patient, Doctor, Appointment, Availability
• Authentification par rôle — redirection automatique selon le profil connecté
• Shadcn/UI — composants accessibles, construits directement en code sans maquette intermédiaire
• Tailwind CSS — styling utilitaire, ajustement UX en temps réel

Entités de base de données

• User — authentification partagée
• Patient — profil et historique
• Doctor — profil et disponibilités
• Appointment — relation patient/médecin avec statut
• Availability — créneaux hebdomadaires paramétrables

Décisions techniques notables

• Shadcn/UI sans maquette : construction directe en code avec ajustement continu — plus rapide que le cycle Figma → dev pour un prototype d'une semaine.
• Authentification par rôle dès le départ : une seule session, deux vues — la logique de redirection est gérée au niveau du middleware, pas dans chaque composant.
• Prisma pour les relations médicales : les contraintes d'intégrité (un rendez-vous appartient à un patient ET un médecin) justifient une base relationnelle plutôt que MongoDB.

Outcome & Results

Prototype fonctionnel livré en une semaine

Toutes les fonctionnalités core opérationnelles :

• Prise de rendez-vous côté patient
• Gestion des disponibilités côté médecin
• Dashboard médecin avec agenda et statistiques
• Calendrier et fiches patients
• Authentification par rôle

Ce que j'ai appris

• Priorisation : se concentrer sur les fonctionnalités vraiment utiles permet de livrer une expérience cohérente sans sacrifier la qualité — même sous contrainte de temps.
• Design médical : dans un contexte médical, clarté et lisibilité ne sont pas optionnelles. Chaque décision UI doit réduire la charge cognitive, pas l'augmenter.
• Prototype ≠ démo : une base technique propre et une architecture pensée dès le départ — ce prototype est extensible, pas jetable.

Learnings & Conclusion

Ce projet m’a permis d’expérimenter une manière de travailler rapide et efficace en construisant un prototype complet en seulement une semaine. L’une des principales leçons a été de comprendre l’importance de prioriser : se concentrer uniquement sur les fonctionnalités réellement utiles permet de gagner du temps sans sacrifier la qualité de l’expérience.

J’ai également appris à utiliser l’IA comme un véritable support de réflexion, autant pour définir la structure du produit que pour accélérer certaines étapes techniques. Avec un cadre clair, l’IA devient un bon outil pour explorer des alternatives rapidement, tout en gardant le contrôle sur les décisions finales.

La réalisation de Doc-Board m’a aussi confirmé qu’un design simple et cohérent est particulièrement adapté dans le domaine médical, où la clarté et la lisibilité sont essentielles. Construire directement dans l’interface, sans passer par des wireframes, m’a permis d’identifier rapidement les points d’amélioration et d’ajuster l’UX au fil du développement.

En conclusion, ce projet représente une base solide pour une éventuelle version plus avancée, intégrant par exemple des retours d’utilisateurs réels ou des fonctionnalités supplémentaires. Il démontre surtout ma capacité à concevoir, designer et développer une application complète dans un délai court, tout en maintenant une cohérence produit et technique.

Gallery