Projet Ticketing — Construire une plateforme de support IT

Le projet Ticketing a été une plongée profonde dans le développement full-stack : concevoir une plateforme web complète permettant à une entreprise de gérer ses incidents informatiques. Du back-end REST avec Node.js à la base de données MySQL, en passant par le front-end responsive et les diagrammes techniques. C'était bien plus qu'un simple formulaire — c'était un vrai système critique pour une entreprise.

Contexte et Objectif

La société GMT, spécialisée dans la création de gestionnaires de tickets web, a été mandatée par une entreprise nommée Société Y pour développer un système de ticketing interne. Notre équipe (groupe de développeurs) avait la responsabilité de :

• Concevoir une architecture full-stack (front, back, BDD)
• Implémenter un système de gestion de tickets complet
• Assurer l'authentification sécurisée sans comptes classiques
• Permettre le suivi horodaté de chaque incident
• Automatiser les notifications par email
• Générer des liens uniques et partageables pour chaque ticket

Les Compétences Développées

Ce projet m'a permis de maîtriser les compétences essentielles du full-stack development :

• Node.js & Express : Construire une API REST robuste avec les bonnes pratiques (routes, middleware, gestion d'erreurs).
• Base de Données MySQL : Concevoir un schéma de données logique, écrire des requêtes SQL optimisées, gérer les relations et les intégrités.
• Front-end Responsive : Créer une interface accessible sur desktop et mobile, ergonomique et intuitive.
• Architecture REST : Comprendre les principes HTTP (GET, POST, PUT, DELETE), les codes de statut, et les bonnes pratiques des API.
• Authentification & Sécurité : Implémenter un système d'authentification basé sur un code unique, protéger les données sensibles, valider les entrées.
• Horodatage & Traçabilité : Assurer que chaque action est correctement datée et traçable (création, mise à jour, réponse, clôture).
• Automation Email : Utiliser Nodemailer pour envoyer automatiquement les réponses des techniciens par email.
• Diagrammes Techniques : Concevoir des diagrammes de classes, de séquence et un Modèle Conceptuel de Données (MCD).
• Documentation Technique : Rédiger une documentation exhaustive pour que le projet soit maintenable et extensible.
• Collaboration & Git : Utiliser Git et GitHub pour versionner le code et collaborer efficacement en équipe.

Les Apprentissages Clés

1. Une application web c'est une conversation

Entre le client qui crée un ticket et le technicien qui répond, il y a une conversation complexe. L'application doit gérer :

• La création d'un ticket avec tous les métadonnées
• L'affectation à un technicien compétent
• La réponse avec horodatage exact
• La clôture ou la réouverture du ticket
• La notification par email à chaque étape

Chaque interaction doit être traçable, sécurisée et vérifiable.

2. Le design de base de données c'est critique

Comment organiser les données pour que les requêtes soient rapides et les relations logiques ? J'ai appris que :

• Une mauvaise structure de BDD ralentit tout le projet
• Les relations (foreign keys, indexes) doivent être pensées à l'avance
• L'historique des tickets (qui a modifié quoi et quand) nécessite une table d'audit
• Les requêtes SQL complexes peuvent être optimisées avec des index intelligents

3. L'API REST doit être prévisible et documentée

Une bonne API, c'est une API que n'importe quel développeur peut comprendre sans poser de questions. J'ai appris que :

• Chaque endpoint doit avoir une responsabilité unique (GET /tickets, POST /tickets, PUT /tickets/:id, etc.)
• Les codes de statut HTTP doivent être corrects (200 OK, 201 Created, 400 Bad Request, 403 Forbidden, 500 Internal Error)
• La documentation doit inclure les paramètres, les réponses d'erreur, et des exemples
• Les validations doivent être strictes (pas de données malformées)

4. L'authentification ne doit pas être basique

Pas de compte utilisateur classique — juste un code unique fourni par l'entreprise. Mais cela pose des questions :

• Comment stocker ce code de manière sécurisée ?
• Comment vérifier qu'un utilisateur est autorisé à voir/modifier un ticket ?
• Comment gérer les cas d'erreur (code expiré, code invalide) ?

J'ai découvert que l'authentification simple peut être très efficace si elle est bien pensée.

5. Les liens uniques et traçables sont une feature

Chaque ticket a un lien unique transmissible au client. Ce lien doit :

• Être difficile à deviner (pas d'ID simple comme 1, 2, 3)
• Permettre au client de consulter son ticket sans authentification
• Être sécurisé (impossible pour un client de voir un ticket d'un autre)

Générer des UUID ou des tokens uniques n'est pas trivial, mais c'est une fonctionnalité puissante.

6. L'horodatage exact est une obligation légale et pratique

Savoir exactement quand une action a eu lieu est critique pour :

• Tracer les responsabilités (qui a fermé ce ticket ?)
• Mesurer les SLA (combien de temps pour répondre ?)
• Déboguer les problèmes (à quelle heure exacte ça s'est passé ?)

Architecture Technique : Structurer la Complexité

Le Back-end (Node.js + Express)

Node.js et Express permettent de créer une API légère et performante. L'architecture incluait :

• Routes organisées par ressource (/tickets, /users, /auth)
• Middleware pour l'authentification, la validation et la gestion d'erreurs
• Controllers pour la logique métier
• Connexion MySQL avec un pool de connexions

La Base de Données

Les tables principales :

• users : les techniciens avec leur code unique
• tickets : les incidents avec tous les métadonnées
• responses : les réponses des techniciens avec horodatage
• audit_log : l'historique de chaque action

Le Front-end

L'interface permettait :

• Créer un ticket (client non authentifié)
• Consulter un ticket avec un lien unique (client)
• Afficher la liste des tickets (technicien authentifié)
• Répondre à un ticket (technicien)
• Marquer un ticket comme résolu (technicien)

Les Défis Rencontrés

« Le défi majeur n'était pas le code, c'était de penser à TOUS les cas limites : que se passe-t-il si le technicien ne répond pas ? Si l'email ne s'envoie pas ? Si deux utilisateurs modifient un ticket en même temps ? »

Plusieurs défis majeurs :

• Concurrence d'accès : Deux utilisateurs modifient un ticket au même temps. Il faut des locks ou du versioning.
• Authentification sans comptes : Comment valider qu'un code est correct sans avoir une vraie base de comptes ?
• Emails non livrés : Si Nodemailer échoue, le ticket est créé mais l'email n'arrive pas. Il faut une queue de emails.
• Performance sous charge : Avec 1000 tickets, les requêtes SQL deviennent lentes. Il faut des indexes.
• Sécurité des liens uniques : Comment s'assurer que personne ne peut deviner un lien d'un autre ticket ?

Diagrammes Techniques : Documenter la Complexité

La documentation incluait :

• Diagramme de Classes : Les entités Ticket, User, Response et leurs relations
• Diagramme de Séquence : Le flux complet : création → assignation → réponse → email → clôture
• Modèle Conceptuel de Données (MCD) : La structure SQL avec toutes les relations
• Endpoints API : La liste exhaustive de toutes les routes REST avec leurs paramètres

Ces diagrammes rendaient le projet accessible même à quelqu'un qui n'avait pas lu le code.

Livrables et Impact

• Application fonctionnelle : Un vrai système de ticketing prêt à être utilisé
• Documentation technique complète : Diagrammes, endpoints API, MCD
• Guide utilisateur : Comment créer, consulter et répondre à un ticket
• Repository Git : Historique clair avec commits organisés
• Code maintenable : Bien structuré, commenté, prêt à être étendu par d'autres

Ce Que Je Retiens Vraiment

Si je devais résumer le projet Ticketing : « Une application web réussie c'est une alchimie : une base de données bien pensée, une API prévisible, une interface ergonomique, et une documentation impeccable. »

J'ai compris que :

• Le full-stack c'est un état d'esprit. Il faut penser à chaque couche (DB, API, front) en même temps.
• Les cas limites sont 80% du travail. Le happy path est facile, c'est tout le reste qui prend du temps.
• La performance c'est une feature. Une application lente = une application rejetée.
• La sécurité n'est jamais finie. Il y a toujours une nouvelle vulnérabilité à considérer.
• La documentation ça se paye toujours. Écrire la doc maintenant = gagner du temps plus tard.
• Tester en vrai c'est indispensable. Les bugs en production coûtent cher.

Et Ensuite ?

Ce projet m'a donné envie d'explorer :

• Les architectures microservices (API Gateway, services indépendants)
• Le scaling et les bases de données distribuées (Redis, PostgreSQL)
• Les tests automatisés (Jest, integration tests)
• Le DevOps et le déploiement automatisé (Docker, CI/CD)
• La performance et l'optimisation (caching, compression, CDN)
• Les websockets pour des applications temps réel

Le projet Ticketing m'a montré que créer une plateforme web, c'est bien plus que du code. C'est concevoir un système robuste, sécurisé et maintenable qui aide les gens à résoudre leurs problèmes. C'est ça qui m'a vraiment motivé à progresser en développement full-stack. Vous pouvez voir le code source ici