« Vibe-coder » un logiciel RH : les risques concrets pour votre entreprise

L’intelligence artificielle évolue vite et change tout dans le monde du travail. Sans surprise, aujourd’hui, c’est une phrase qu’on entend de plus en plus : « Honnêtement, on pensait juste se faire coder ça nous-mêmes avec l’IA. »

Et honnêtement, on comprend l’attrait initial! On ouvre un outil d’IA, on décrit ce qu’on veut, et quelques heures plus tard, on a quelque chose qui ressemble à un système RH. Pas besoin de contrat fournisseur, ou d’appels d’implantation, et surtout de facture mensuelle. Pour un propriétaire-dirigeant ou une adjointe administrative qui jongle déjà avec quinze dossiers avant le dîner, c’est un raccourci séduisant.

Voici le problème : un SIRH n’est pas un projet de fin de semaine. C’est le système qui détient les numéros d’assurance sociale de vos employés, leurs salaires, leurs demandes d’accommodement médical, et les CV et vérifications d’antécédents de vos candidats. Quand ce système échoue, il n’échoue pas discrètement : il échoue sous forme de fuite de données, de manquement à la Loi 25, ou d’une conversation très inconfortable avec quelqu’un dont les renseignements personnels viennent de se retrouver dans la nature.

Voici donc, honnêtement, tout ce qui peut mal tourner quand vous décidez de « vibe-coder » votre SIRH.

Qu’est-ce que « vibe-coder son SIRH » veut vraiment dire

Le vibe coding consiste à bâtir un logiciel en décrivant à une IA ce qu’on veut, et en acceptant ce qu’elle génère, avec peu ou pas de révision manuelle du code produit. C’est très bien pour un prototype, un script interne, ou une petite appli sans trop d’impact organisationnel et dont personne ne dépend. Ça devient tout autre chose quand le résultat traite les données personnelles de chaque employé et candidat de votre entreprise.

Les risques concrets de « vibe-coder » un logiciel RH

1. La sécurité n’a été planifiée

Un vrai logiciel RH passe par des décisions d’architecture de sécurité avant même qu’une seule fonctionnalité soit codée : comment les données sont chiffrées au repos et en transit, comment les sessions sont gérées, comment les permissions sont découpées.

Une IA qui génère du code à la volée ne prend pas ces décisions de façon délibérée. Elle produit du code qui a l’air plausible, mais « plausible » n’égale pas « sécuritaire ». Des chercheurs en sécurité ont montré à répétition que le code généré par IA reproduit des failles bien connues (identifiants codés en dur, authentification brisée, entrées non validées) à un taux nettement plus élevé que le code révisé par un processus de sécurité.

2. Vous ne savez pas vraiment où vivent vos données

Posez-vous la question : si vous vibe-codiez votre base de données RH demain, pourriez-vous affirmer avec certitude quel fournisseur infonuagique l’héberge, dans quel pays se trouvent les serveurs, et qui d’autre a accès à l’infrastructure? La plupart des gens qui construisent ainsi ne peuvent pas répondre, parce que l’IA a choisi les paramètres par défaut, et ces paramètres sont rarement pensés avec la conformité en tête. La souveraineté des données n’est pas un luxe quand on parle de dossiers d’employés. C’est une question qui mérite une vraie réponse, pas un « je présume que c’est correct ».

3. Personne ne vérifie qui a accès à quoi

Dans un vrai SIRH, l’accès est basé sur les rôles : un gestionnaire voit les données de son équipe, la paie voit la rémunération, et personne ne voit les notes médicales à moins d’en avoir vraiment besoin. Bien faire ce travail est fastidieux et peu glorifiant, donc exactement le genre de chose qu’on saute en silence quand on optimise pour « est-ce que ça fonctionne techniquement ». Le résultat, le plus souvent : un système où le contrôle d’accès est une réflexion après coup, ou n’existe tout simplement pas.

4. La conformité n’est pas assurée

Que ce soit la Loi 25 au Québec, la LPRPDE au fédéral, ou les exigences sectorielles de conservation des dossiers de paie, les données RH viennent avec des obligations légales (et les risques qui s’ensuivent si vous ne les respectez pas). Un fournisseur qui prend ces questions au sérieux peut vous montrer une certification SOC 2 Type II et expliquer exactement comment il répond à ces obligations. Ce n’est pas le cas d’un système vibe-codé en vitesse, et ajouter la conformité après coup à un logiciel qui n’a pas été pensé pour ça est bien plus difficile que de la construire dès le départ.

5. Les données des candidats sont un risque sous-estimé

On a tendance à penser ce risque uniquement en fonction des employés actuels, mais votre bassin de candidatures est probablement encore plus exposé. Un CV contient souvent plus de détails personnels qu’un dossier d’employé : adresse, numéro de téléphone, parfois statut d’immigration ou information de santé divulguée volontairement.

Ces données touchent votre système avant même que vous ayez décidé d’embaucher la personne, ce qui veut dire qu’une fuite à cette étape touche des gens qui n’ont jamais accepté de devenir vos employés et n’ont aucune relation continue avec votre entreprise sur laquelle s’appuyer.

6. Sans journal d’audit, pas de réponses quand quelque chose tourne mal

Si le salaire d’un employé est consulté par quelqu’un qui n’aurait pas dû le voir, pouvez-vous retracer exactement qui a consulté quoi, et quand? Dans un vrai SIRH, c’est une fonctionnalité de base. Dans un système vibe-codé, elle n’existe probablement pas, ce qui veut dire que si un incident survient, vous n’aurez pas juste une fuite, vous aurez une fuite sur laquelle vous ne pourrez même pas enquêter correctement.

7. « L’IA l’a écrit » n’égale pas « quelqu’un l’a testé »

Il y a une présomption silencieuse selon laquelle, parce qu’une IA a généré le code, celui-ci serait forcément plus fiable que ce qu’une personne aurait pu construire. C’est l’inverse : personne ne l’a écrit avec intention, et (c’est le point critique) personne n’est responsable de l’avoir révisé.

Un développeur qui laisse passer une vulnérabilité peut être questionné sur ce qu’il avait en tête. Une IA ne peut pas être tenue à cette même norme, et souvent, personne dans l’équipe n’a l’expertise en sécurité pour repérer ce qui a été manqué.

8. Il n’y a personne à appeler quand quelque chose cloche

Quand un logiciel fournisseur rencontre un problème, vous ouvrez un billet de support. Quand le code qu’une IA vous a généré brise, vous êtes seul; ou pire, la seule personne qui comprenait comment tout ça tenait ensemble a quitté l’entreprise depuis.

C’est la dette technique cachée derrière chaque « on va juste se le faire nous-mêmes » : le système fonctionne bien jusqu’au jour où il ne fonctionne plus, et il n’y a alors ni contrat de service, ni support, ni personne avec le contexte pour réparer rapidement.

9. Le vrai coût apparaît plus tard, pas maintenant

Le vibe coding semble gratuit le premier mois. Le vrai coût (une fuite, une sanction liée à la Loi 25, des semaines de travail technique pour rapiécer un système que plus personne ne comprend, ou une reconstruction complète une fois le risque réalisé) apparaît bien plus tard.

Que faire à la place?

Vous l’aurez compris, la barre pour « un logiciel qui touche aux données personnelles d’employés et de candidats » devrait être plus haute que pour « un logiciel de suivi d’inventaire ». Au minimum, cherchez un fournisseur capable de vous montrer des certifications de sécurité vérifiées de façon indépendante, une réponse claire sur l’hébergement des données, et un contrôle d’accès par rôle dès le départ.