Site corporate international sous Drupal : API REST (OpenAPI) et intégration d’un ATS de recrutement

Le besoin : un site qui parle à d’autres systèmes

Pour un groupe international, un site corporate n’est pas une île : il doit afficher des offres d’emploi qui vivent dans un logiciel RH, présenter des équipes et des entités maintenues ailleurs, et parfois exposer tout cela à d’autres applications. Le vrai sujet n’est donc pas « faire des pages », mais faire circuler la donnée proprement — sans double saisie, sans copier-coller, sans divergence entre le site et les systèmes sources. C’est un travail d’intégration, et c’est là que se joue la valeur.

Modéliser le bon contenu

Avant toute intégration, il faut un modèle de contenu juste. Nous avons structuré trois briques métier : les offres d’emploi (avec leurs taxonomies — métiers, lieux, types de contrat), les profils d’équipe, et les entités du groupe (business units). Chaque brique a ses champs, ses relations et ses règles. Un modèle propre en amont, c’est ce qui rend l’intégration et l’API prévisibles ensuite — plutôt qu’un empilement de champs improvisés au fil des besoins.

Intégrer l’ATS de recrutement : une synchronisation, pas un copier-coller

Les offres d’emploi ne sont pas saisies dans Drupal : elles vivent dans un ATS de recrutement (TalentSoft). Nous avons développé une synchronisation planifiée — une commande exécutable en tâche de fond — qui interroge la source, crée ou met à jour les offres correspondantes dans Drupal (upsert), et retire automatiquement les offres devenues obsolètes. Résultat : le site est toujours à jour, personne ne ressaisit une annonce à la main, et l’ATS reste la source de vérité. La même logique sert à importer les profils d’équipe. C’est une intégration robuste, tracée et rejouable — pas un import ponctuel.

Exposer une API REST documentée (OpenAPI)

Une fois la donnée propre dans Drupal, il faut pouvoir la redistribuer. Nous avons construit une API REST sur-mesure exposant les ressources métier — liste et détail des offres d’emploi, leurs taxonomies et vocabulaires, les entités du groupe — avec une documentation OpenAPI générée automatiquement. Techniquement : des ressources REST dédiées, des param converters pour résoudre proprement les entités depuis l’URL, et un event subscriber pour maîtriser le routage de l’API. L’intérêt pour une agence : cette API est documentée, versionnable et consommable — par le front du site, une application tierce, ou un futur projet — au lieu d’être une logique enfouie dans des templates.

Multilingue de bout en bout

Un groupe international parle plusieurs langues, et le multilingue ne s’arrête pas au contenu éditorial : il traverse le modèle, l’interface et l’API. Les contenus sont traduits et servis par langue, y compris via les points d’entrée de l’API. C’est ce qui permet d’alimenter des interfaces localisées sans dupliquer la logique — un seul socle, plusieurs marchés.

Emailing et relation

Au-delà du contenu, le site déclenche des communications. Nous avons intégré une solution d’emailing (Mailify) pour connecter formulaires et parcours à l’outil de relation du groupe, avec un envoi maîtrisé côté serveur. Là encore, la règle est la même : le site ne réinvente pas un outil, il s’intègre à celui qui fait déjà autorité.

Performance et robustesse, sans y penser

Une intégration n’a de valeur que si elle tient la charge et reste fluide. Le socle embarque une gestion fine du cache (contextes de cache adaptés, dont la distinction mobile / desktop), des détails d’expérience comme le temps de lecture, et la chaîne qualité habituelle — revue de code outillée, intégration continue — pour que les évolutions n’introduisent pas de régression. Ce n’est pas le sujet vendeur du projet, mais c’est ce qui fait qu’il tourne sans surprise.

Reprendre ou faire évoluer une intégration API

C’est le point qui parle à une agence : un site truffé d’intégrations fait peur à reprendre — sauf s’il est fait proprement. Ici, tout est lisible et documenté : le modèle de contenu est explicite, la synchronisation est une commande isolée et rejouable, l’API est décrite en OpenAPI, et la qualité est outillée. On sait auditer une intégration existante, comprendre le flux entre le système source et Drupal, et l’étendre — ajouter une ressource à l’API, brancher une nouvelle source, ouvrir une langue — sans tout démonter.

Questions fréquentes

En clair : ce projet n’est pas « un site de plus » : c’est une plateforme d’intégration. La valeur est dans le flux — une donnée qui vient d’un ATS, se range dans un modèle propre, et ressort par une API documentée, le tout multilingue et maintenable. C’est exactement le type de Drupal « connecté » qu’une agence cherche à déléguer.