Devlog #1 – Roadmap & authentification sécurisée

🚀 Focus fonctionnel : Les premières briques

Voici les premières briques / milestones du projet :

1. Clean Init

Reprise de zéro : recréation d’un monorepo sain avec une structure claire (apps/api, apps/web, packages/…), et mise en place des bases pour la qualité :

• Frameworks à jour
• Des tests unitaires avec des examples
• Une suite de test e2e avec Playwrigt
• Une base solide de documentation
• Une authentication propre et sécurisée en place (plus sur ce sujet dans le focus technique du jour !)

2. Profil

Chaque JetPeople aura un espace personnel, où il pourra bientôt consulter son level, ses compétences, ses objectifs, son historique… C’est la base de tout l’accompagnement personnalisé à venir.

3. Journal de bord

C’est le module qui regroupera tous les entretiens réalisés : annuels, professionnels, sexennaux et suivis de mission. Un espace clair, centralisé, accessible à tout moment.

Avec cette première “vraie” feature, je compte déjà mettre le suivi de chacun au centre du projet et permettre à tout le monde de se familiariser avec la plateforme.

4. Trajectoires de carrière

Cœur du projet : la mise en place des Jobs et de leurs spécialités sous forme de Job Ladder.

Exemples :

• Software Engineer → Frontend, Backend, Fullstack, Mobile
• QA Engineer → Manual, Automation
• Design → UI, UX, Research

Chaque niveau est découpé avec des objectifs clairs et actionnables, permettant de comprendre comment progresser et se situer à tout moment.

5. Galaxie des compétences

Un outil interactif pour cartographier son parcours au sein de la galaxie des compétences, le but est de pouvoir explorer/découvrir des nouveaux sujets à apprendre, pouvoir visualiser où l’on en est, mais aussi d’avoir une cartographie complète pour Jetdev. Je pense vraiment que cet outil va nous aider à voir plus clair sur comment et vers quoi progresser et créer beaucoup d’échange du fait que nous allons compléter cette galaxie ensemble.

🤓 Pour les geeks qui me lisent, je vois ce module comme le manuel de potions du Prince de Sang-Mêlé dans Harry Potter, un recueil de connaissances que l’on va pouvoir annoter graçe à nos diverses experiences.

6. Kickstart du MVP

Démarrage officiel en production même si j’espère que des premiers utilisateurs auront déjà commencé a s’approprier l’outil au cours du développement du MVP.

---

🔐 Focus technique : Authentification et choix d’architecture

Quand on manipule des données RH, la sécurité est non négociable (non, personne n’aura accès à la base de prod 😜).
La première brique posée côté technique, c’est donc l’authentification via Google OAuth2.

Mini ADR – Google OAuth vs Firebase Auth

Si tu as vu mon talk sur la Hype tu sais que les ADR c’est mon kiff, et j’ai donc profiter de l’occasion pour te faire un exemple 👇.

Contexte

Pour Pathfinder, on a besoin d’un système d’authentication sécurisé pour que les JetPeople puissent se connecter via leur compte Google — une manière simple et centralisée de gérer les accès.

Plusieurs options on été envisagées :

1. Firebase Authentication : SDK coté frontend + Vérification coté backend via l’Admin SDK)
2. Google Oauth2 - Utilisation du token Google : Auth.js Authorization Code avec PKCE coté NextJS et Verification côté NestJS
3. Google Oauth2 - Token custom : Authentication gérée complètement dans par back-end avec notre propre logique de gestion de session / refresh tokens grâce notamment à @nestjs/jwt et Passport.

Comparatif

Option	Avantages	Inconvénients
1. Firebase Authentication	✅ Intégration rapide ✅ Pleins d’exemples chez Jetdev ✅ Dashboard de gestion intégré	⚠️ Dépendances supplémentaires ❌ Vendor lock-in (Firebase) ❌ On n’a besoin que de la partie Google
2. Google OAuth2 — Token Google (PKCE)	✅ Standard OAuth2 ✅ Intégration rapide avec Next.js (Auth.js) ✅ Pas de projet firebase à maintenir	⚠️ Moins de contrôle sur les sessions/tokens ⚠️ Un token Google circle entre le back et front (pas idéal)
3. Google OAuth2 — Token custom (backend-controlled)	✅ Contrôle total (JWT, refresh tokens, rôles) ✅ Base pour auth centralisée multi-apps ✅ Pas de projet firebase à maintenir	❌ Plus complexe à mettre en œuvre ❌ Nécessite une logique de session robuste côté backend

Décision

Après comparaison, j’ai opté pour la solution 2, qui offre un bon compromis entre rapidité de mise en place et évolutivité.

Cette solution repose sur :

• L’utilisation de Auth.js côté Next.js pour gérer le flow OAuth2 avec PKCE.
• La récupération de l’id_token Google lors du login.
• L’envoi de l’id_token dans le header Authorization pour chaque appel frontend → backend.
• Une vérification du token côté NestJS, via la bibliothèque google-auth-library.

Pourquoi avoir fait ce choix ?

• Intégration super rapide (ndlr: j’ai mis une bonne heure de taf).
• Pas besoin de gérer et intégrer la partie Firebase (même s’il ne s’agit pas d’une grosse charge).
• Je suis ok avec le fait que le backend n’émet pas de JWT interne : il fait confiance au token Google directement.

Une solution simple mais extensible avec la possibilité d’évoluer vers une stratégie de tokens personnalisés plus tard si besoin.

Voici le flow complet :

Comment on implémente ça ?

Coté Next.js

• Création d’un OAuth 2.0 Client ID dans la console Google Cloud
• Mise en place de Auth.JS avec le provider Google en suivant le guide
• Ajout de callbacks pour rendre l’id token dispo dans la session JWT
• Ajout d’une callback sur le sign pour synchroniser l’utilisateur dans le backend

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [Google],
  callbacks: {
    async signIn({ profile }) {
      const res = await fetch(
        `${process.env.BACKEND_URL}/auth/internal/users/sync`,
        {
          method: "POST",
          headers: {
            "Content-Type": "application/json",
            Authorization: `Bearer ${process.env.INTERNAL_SECRET}`,
          },
          body: JSON.stringify({
            providerId: profile?.sub,
            email: profile?.email,
            firstName: profile?.given_name,
            lastName: profile?.family_name,
          }),
        },
      );

      return res.ok;
    },
    async jwt({ token, account }) {
      if (account?.id_token) {
        token.idToken = account.id_token;
      }
      return token;
    },
    async session({ session, token }) {
      session.idToken = token.idToken;
      return session;
    },
  },
});

Coté NestJS

• Ajout d’un AuthModule dans l’API
• Création d’un Guard qui utilise google-auth-library pour vérifier le token

@Injectable()
export class GoogleAuthGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC_KEY, [
      context.getHandler(),
      context.getClass(),
    ]);
    if (isPublic) {
      return true;
    }

    const request: Request = context.switchToHttp().getRequest();
    const authHeader = request.headers["authorization"];

    if (!authHeader || authHeader.startsWith("Bearer ")) {
      throw new UnauthorizedException(
        "Missing or invalid Authorization header",
      );
    }

    const idToken = authHeader.split(" ")[1];

    try {
      const ticket = await client.verifyIdToken({
        idToken,
        audience: process.env.GOOGLE_CLIENT_ID,
      });

      const payload = ticket.getPayload();

      if (!payload || !payload.email) {
        throw new UnauthorizedException("Invalid token payload");
      }

      request["user"] = {
        email: payload.email,
        sub: payload.sub,
        name: payload.name,
        picture: payload.picture,
      };

      return true;
    } catch (error) {
      throw new UnauthorizedException("Invalid Google ID Token");
    }
  }
}

Ce que ça apporte au projet

• Authentification sécurisée et centralisée
• Gestion des utilisateurs synchronisée entre frontend et backend
• Base prête pour restreindre des fonctionnalités ou visualiser un espace personnel

Pistes d’amélioration

Changement de la stratégie de session

Auth.js propose deux stratégies de session, la stratégie basée sur les JWT est actuellement mise en place, car elle ne nécessite pas de connexion à la base de donnée, ce qui permet de conserver NestJS comme unique connexion à la base de donnée.

Basculer sur la stratégie base de donnée nous permettrait de limiter l’exposition des tokens et d’ajouter des features comme pouvoir invalider des sessions (sign out everywhere par exemple).

---

💬 Prochain devlog :

Je vous parlerai des trajectoires de carrière chez Jetdev et de la stratégie de tests ✨ Rejoins le salon #pathfinder-discovery pour suivre l’aventure et n’hésite pas consulter le projet sur Github 🚀

---