Recruter un ingénieur Rails quand l’IA écrit le code

Pour recruter un ingénieur Rails dans une startup, commencez par définir le produit qu’il devra faire évoluer et maintenir. Demandez ensuite à chaque candidat d’apporter une modification délimitée à une application Rails existante. Évaluez sa capacité à cadrer le changement, à protéger les données, à écrire des tests utiles et à préparer la mise en production. Utilisez les mêmes questions et la même grille fondée sur des comportements observables, qu’il écrive le code lui-même ou avec l’aide de l’IA.

La question prend un relief particulier depuis l’essai du 24 septembre de Jared Norman, « What About Rails? ». Il s’interroge sur ce que la conférence d’ouverture de Rails World a dit de Rails lui-même, alors que le code généré par IA et la nouvelle architecture d’un produit phare occupaient le devant de la scène. Une discussion sur Hacker News a réuni des points de vue divergents de praticiens. Ni un essai ni des commentaires ne peuvent décider qui vous devez recruter. Votre application, ses risques et les travaux à venir, si.

De quoi un ingénieur Rails est-il responsable dans une petite startup ?

Dans une petite startup, l’ingénieur Rails est responsable d’un produit qui doit continuer à fonctionner, pas seulement d’une succession de commits. Son travail peut toucher aux requêtes, aux données, aux interfaces, aux tâches en arrière-plan, aux intégrations, aux tests, aux mises en production et aux incidents. Précisez lesquelles de ces responsabilités feront réellement partie du poste.

Imaginez une équipe de deux ingénieurs qui exploite une application Rails. Un client demande une exportation. La fonction visible se résume peut-être à un bouton et à un fichier. Le travail d’ingénierie consiste aussi à déterminer qui peut demander l’exportation, quelles données appartiennent au compte, comment traiter une demande volumineuse, quoi faire en cas d’échec et comment déployer la fonction. Un candidat qui crée le bouton sans pouvoir expliquer la séparation des données entre comptes passe à côté de l’enjeu le plus coûteux.

Rails fournit un cadre commun pour ce travail. La doctrine Rails privilégie les conventions, les composants intégrés et la possibilité de les remplacer lorsque c’est nécessaire. Une bonne recrue sait suivre le chemin établi dans l’application, du contrôleur au modèle puis à la vue ou à la tâche, et justifier tout écart. Elle n’a pas à exiger que toutes les applications Rails se ressemblent. Les conventions d’une équipe sont des choix faits dans le cadre du framework, pas des règles universelles.

Il faut aussi maintenir l’application dans un état exploitable. Au 27 septembre 2026, le journal des versions de Rails indique que la version 8.1.4 est sortie le 24 septembre. La politique de maintenance de Rails annonce des corrections de bugs pour la branche 8.1.x jusqu’au 10 octobre 2026 et des correctifs de sécurité jusqu’au 10 octobre 2027 ; la prise en charge de sécurité de la branche 8.0.x court jusqu’au 7 novembre 2026. Ces dates évolueront. Ce qui compte pour le recrutement, c’est la capacité à inventorier la version et les dépendances de l’application, à planifier une mise à jour, à la tester et à rétablir le service si elle tourne mal.

Si vous n’avez pas d’application Rails et que le travail appelle une autre plateforme, ne faites pas de la connaissance de Rails un filtre de recrutement. Notre guide pour recruter un premier ingénieur traite plus largement des responsabilités d’une première recrue technique.

L’IA a-t-elle changé les raisons de recruter une expertise Rails ?

L’IA peut changer qui rédige la première version d’une modification. Il faut toujours quelqu’un pour décider si cette modification répond au besoin produit, protège les utilisateurs et tient en production. Évaluez la manière de travailler que vous attendez de la future recrue.

Norman estime que la conférence a donné peu d’indications sur l’avenir de Rails. Il conteste aussi l’idée selon laquelle il serait inutile de lire le code généré. C’est son interprétation d’une intervention et du développement assisté par IA, pas la politique de maintenance du projet Rails. Sur sa page consacrée à Rails et à l’IA, le projet explique que les noms, dossiers, commandes et pratiques habituels aident les agents à produire des modifications conformes aux usages de Rails. Il publie également des évaluations ciblées, notamment des demandes de fonctionnalité dans Fizzy et de petites tâches portant sur des API Rails. Ce sont des tests circonscrits, publiés par le projet lui-même. Ils ne démontrent ni qu’un agent peut maintenir votre application sans relecture, ni qu’un candidat qui utilise un tel outil est meilleur ou moins bon.

Les commentaires sur Hacker News divergent quant à la valeur et à la maintenabilité du code généré. Ce sont des témoignages, pas une règle de recrutement.

Demandez plutôt au candidat de montrer les décisions qu’il a prises face au code généré. Quelle hypothèse a-t-il vérifiée ? Quelle suggestion a-t-il écartée ? Peut-il retracer le chemin de l’autorisation sans demander à l’agent de lui expliquer sa propre modification ? Pourrait-il réduire de moitié le changement tout en répondant au besoin ? Ces questions valent aussi pour un candidat qui n’a pas utilisé l’IA. La pratique de relecture s’observe ; un nombre déclaré de lignes écrites n’en tient pas lieu.

Si le choix de Rails reste ouvert, examinez les interfaces nécessaires, les exigences de performance, les intégrations, l’existant, les capacités de l’équipe et l’horizon de maintenance. Le changement d’architecture d’un autre produit ne peut pas décider de la vôtre. Pour une application Rails établie, « responsable de cette base de code Rails » décrit mieux le poste que « développeur IA ».

Quelles compétences Rails inscrire dans l’offre d’emploi ?

Listez les compétences nécessaires dès l’arrivée, puis distinguez les conventions qu’un ingénieur compétent pourra apprendre après son recrutement. Vous rattacherez ainsi le poste au travail réel, sans faire de l’entretien un concours de détails appris par cœur.

Commencez par un inventaire concret. Quelle version de Rails utilisez-vous ? Où vérifiez-vous l’appartenance des données à un compte ? Les changements portent-ils surtout sur des pages rendues par le serveur, des API, des tâches en arrière-plan ou des intégrations ? Qui déploie et enquête sur les incidents ? Que prévoit la feuille de route du prochain trimestre ? Résumez les réponses dans une courte description du poste. Le guide de recrutement d’un ingénieur full-stack peut vous aider si le poste couvre à la fois l’interface et le serveur ; le seul intitulé « Rails » ne définit pas cet équilibre.

Pour maintenir une application multitenant, les compétences nécessaires dès le premier jour pourraient être les suivantes :

• Suivre une requête ou une tâche en arrière-plan jusqu’aux données qu’elle lit et modifie.
• Expliquer comment l’autorisation et le périmètre du compte s’appliquent au changement précis.
• Ajouter ou adapter un test de régression utile, y compris pour un cas d’échec.
• Lire une migration et décrire les risques de déploiement et de retour arrière.
• Respecter les conventions de la base de code et expliquer une solution plus simple lorsqu’elle existe.
• Signaler les incertitudes avant de modifier un comportement visible par les clients.

Vous pouvez exiger une maîtrise plus approfondie de Rails si cette personne sera immédiatement seule à maintenir l’application. Dites-le clairement. Si l’équipe peut accompagner un bon ingénieur venu d’un autre environnement, privilégiez les preuves d’un raisonnement transférable à la connaissance d’une méthode auxiliaire particulière. Une exigence de familiarité doit découler du poste, pas des habitudes d’entretien.

Cette distinction rejoint les recommandations de l’Office of Personnel Management (OPM) américain sur l’analyse des postes, qui relient les évaluations aux tâches et aux compétences requises. Ses recommandations sur les échantillons de travail déconseillent également d’évaluer des compétences que la personne doit apprendre après son arrivée. Ce sont des principes généraux de sélection issus de la fonction publique américaine, pas une liste de critères validée pour une startup Rails.

Comment évaluer le jugement Rails sans questionnaire de connaissances ?

Donnez aux candidats une petite application Rails fictive et une modification proche du travail annoncé. L’exercice doit leur permettre de montrer où placer le comportement, comment protéger les données et comment vérifier le résultat. Il ne doit pas masquer une demande de terminer votre propre liste de fonctionnalités.

L’exemple qui suit est une proposition originale à tester, pas une évaluation validée. Une application fictive à deux comptes contient déjà des utilisateurs, des rapports et une tâche en arrière-plan. Un administrateur souhaite exporter les rapports de son compte. Le dépôt comprend les instructions d’installation, des données fictives, le schéma, les tests existants et une commande unique pour les lancer. Donnez à tous les candidats le même dossier et une règle explicite sur l’IA et les ressources extérieures.

N’exigez pas une file de tâches simplement pour vérifier que le candidat en connaît le fonctionnement. Dans cet exemple, une tâche existe déjà : le candidat peut s’en servir si le comportement de l’application le justifie. Celui qui explique pourquoi un traitement synchrone suffit pour une petite exportation bornée peut faire preuve d’un meilleur jugement que celui qui multiplie les composants. À l’inverse, un candidat qui ignore une contrainte connue sur le volume des données doit pouvoir expliquer ce choix.

Testez le dossier avec un ingénieur, annoncez l’effort attendu et vérifiez une copie fraîche du dépôt. Si l’installation se transforme en réparation des dépendances, vous mesurez surtout la patience face à votre environnement. Pour un poste centré sur l’interface, remplacez l’exportation par un changement d’état et un parcours d’erreur avec Hotwire ; pour un poste d’exploitation, proposez un scénario de déploiement ou d’incident. L’exercice doit refléter le travail annoncé.

Le guide de sécurité Rails et le guide de test Rails apportent un contexte technique pour examiner la solution. Les outils du framework peuvent réduire certains risques courants, mais ils ne décident pas si cet administrateur peut accéder aux rapports d’un autre compte. Les tests peuvent vérifier ce comportement ; encore faut-il que le candidat choisisse de tester le chemin dangereux. L’intérêt de l’exercice est de pouvoir discuter de ces décisions à partir d’une modification réelle. Sa capacité à prédire la réussite d’un recrutement n’a pas été validée.

Pour mieux cadrer l’effort et rédiger les consignes, consultez notre guide sur les exercices de code.

Quelles questions poser et que noter ?

Posez à tous les candidats les mêmes questions fondamentales liées au poste, puis évaluez les éléments observés selon des repères rédigés avant les entretiens. L’échange doit éclairer leur raisonnement sur leur modification, y compris sur les éventuelles propositions de l’IA, sans devenir une démonstration de vocabulaire Rails.

Pour le dossier d’exportation, utilisez ces cinq questions :

1. Où ce comportement doit-il se trouver dans l’application existante, et pourquoi l’avez-vous placé là ?
2. Quelle limite entre comptes ou quelles autorisations vous préoccupent le plus ? Montrez où elles sont appliquées.
3. Quelle régression votre test le plus utile détecterait-il ? Que laisserait-il sans couverture ?
4. Que vérifieriez-vous avant la mise en production, et comment réagiriez-vous si l’exportation échouait ?
5. Si vous avez utilisé l’IA, quelle suggestion avez-vous modifiée ou rejetée, et pourquoi ? Sinon, quelle autre approche avez-vous envisagée puis écartée ?

Présentez ensuite à chaque candidat la même évolution fictive : les exportations s’exécutent désormais de façon asynchrone, et l’administrateur perd son accès au compte avant leur exécution. Demandez ce qu’il faut changer, notamment pour vérifier les droits au moment de produire l’exportation, puis au moment de la transmettre ou de la télécharger. Il n’existe pas de réponse obligatoire en une phrase. Cherchez à savoir si le candidat repère le décalage temporel, ses conséquences pour l’utilisateur et les deux moments où l’accès doit être vérifié. Il peut aussi expliquer que le dossier ne contient pas assez d’informations pour arrêter une règle définitive. C’est un élément utile s’il précise ce qu’il lui faudrait pour trancher.

Les recommandations de l’OPM sur les entretiens structurés préconisent des questions prédéfinies liées au poste et des critères de notation communs. Les questions et repères ci-dessous sont proposés par cet article, pas approuvés par l’OPM. Testez-les pour votre poste.

Notez les observations, pas l’aisance à se présenter. Les évaluateurs devraient consigner ce qu’ils ont vu avant de discuter ensemble de la note. « A repéré une requête non limitée au compte et ajouté un test entre comptes » est une observation ; « semble expérimenté » n’en est pas une. Un candidat qui propose une autre conception valable doit pouvoir obtenir une bonne note. Si le poste permet explicitement de monter en compétence sur Rails, ne pénalisez pas quelqu’un simplement parce qu’il consulte la documentation d’une API.

Les travaux généraux sur la sélection, dont la réanalyse de Sackett et ses collègues et leur article de suivi, éclairent les évaluations structurées dans leur ensemble. Ils ne valident ni cette grille Rails, ni sa règle sur l’IA, ni cet échange. Testez-les et ajustez-les. Notre guide des grilles d’évaluation structurées traite du processus de décision plus large.

Comment rendre l’évaluation équitable et facile à maintenir ?

Un échantillon de travail n’est utile que si les candidats qualifiés peuvent le réaliser dans des conditions comparables. Annoncez l’effort attendu, les règles d’utilisation des outils, les critères d’évaluation et le format de remise. Vérifiez ensuite que les candidats peuvent effectivement participer dans les conditions prévues.

Les règles sur l’IA font partie de la conception de l’évaluation. Si votre équipe utilise des agents dans son travail, les autoriser pendant l’exercice peut montrer comment le candidat vérifie leurs propositions. Donnez à tous les mêmes consignes sur les outils autorisés, le traitement des données et la nécessité éventuelle de services payants. N’exigez pas la transcription d’une conversation avec une IA comme preuve de paternité du code. Demandez aux candidats d’expliquer leurs décisions pendant l’échange. Si vous interdisez l’IA pour un poste donné, expliquez en quoi cette restriction correspond au travail et appliquez-la de façon cohérente.

Testez l’exercice avant de le proposer. Demandez à un ingénieur de le réaliser depuis une copie fraîche du dépôt, en relevant les difficultés d’installation et le temps effectivement passé. Raccourcissez une tâche trop longue. Prévoyez un autre format ou un aménagement lorsque le format standard empêche une personne qualifiée de participer. Aux États-Unis, les recommandations de l’EEOC destinées aux employeurs constituent un point de départ concernant les obligations d’aménagement ; les autres juridictions ont leurs propres règles. L’engagement pratique est simple : les candidats doivent savoir comment demander un aménagement sans devoir en parler à chaque évaluateur.

Entretenez le dossier comme un logiciel. Fixez ou indiquez les versions de Rails et de Ruby, assurez-vous que les dépendances restent installables, lancez les tests en intégration continue et retirez les indices involontaires des données de départ. Lorsque le poste évolue, revoyez l’exercice et les repères de notation. Suivez les abandons et les demandes de clarification récurrentes : ils peuvent révéler un dossier défectueux plutôt que des candidats insuffisants. Ne réutilisez pas indéfiniment une tâche parce qu’elle a fonctionné une fois.

Enfin, laissez aux évaluateurs le temps de lire la modification. Si le processus ne récompense qu’une exécution de tests réussie, vous manquerez les décisions que cet article vous invite à examiner. Un échange bref et cohérent peut révéler une hypothèse cachée, mais il ne peut pas rendre après coup un mauvais échantillon de travail pertinent pour le poste.

Comment utiliser Kit pour ce processus ?

Kit peut coordonner le parcours du candidat pendant que votre équipe définit l’évaluation. Son pipeline de recrutement comprend des exercices de code reposant sur GitHub, ainsi que des étapes distinctes d’entretien et de revue d’équipe, avec des critères de notation pour les étapes qui les prennent en charge. Ces éléments permettent d’organiser un dossier testé, une échéance et un échange humain, sans prétendre qu’un produit peut certifier le jugement d’un ingénieur Rails.

Pour un exercice de code, Kit crée un dépôt privé à partir d’un modèle GitHub et fixe une échéance. Placez votre application fictive et les consignes dans ce modèle. Utilisez une étape ultérieure de revue ou d’échantillon de travail pour les critères de notation et les éléments tirés de la modification. Ne considérez pas l’étape d’exercice comme un juge automatique de l’architecture ou de la sécurité. Kit ne génère pas cette grille, ne prouve pas qui a écrit chaque ligne et n’anime pas l’échange à votre place.

Kit est lui-même une application Rails. Ses pages de recrutement destinées aux utilisateurs emploient Hotwire, tandis que des outils MCP distants et authentifiés donnent accès à des opérations de recrutement pour les agents par une voie distincte. C’est un exemple concret de coexistence entre interface utilisateur et accès pour les agents. Cela ne prouve ni que Rails est la bonne architecture pour toutes les startups, ni que l’accès des agents remplace la relecture humaine.

La prochaine étape est modeste : rédigez une description d’une page du poste, testez avec votre équipe une seule modification Rails bien délimitée et accordez-vous sur les critères avant d’inviter des candidats. Si vous cherchez où organiser l’exercice et les revues suivantes, découvrez Kit. Il vous revient toujours de déterminer ce qu’est un bon ingénieur pour votre application.