Adopter Rust : quelles compétences recruter ou enseigner ?

Un parcours d’intégration à Rust doit montrer à un ingénieur comment compiler, tester, expliquer et modifier votre base de code avec une revue adaptée. Avant d’exiger une expérience de Rust à l’embauche, déterminez les responsabilités qui demandent une expertise immédiate et celles que l’équipe peut enseigner par un travail accompagné. Inscrivez cette distinction dans la définition du poste et le programme de formation.

Une équipe peut se tromper dans les deux sens. Elle peut écarter un ingénieur compétent parce qu’il ne connaît pas une syntaxe qu’elle pourrait lui enseigner. Elle peut aussi recruter une personne motivée pour apprendre, puis lui confier un poste sans prévoir qui relira son travail. Un parcours d’intégration vous aide à voir quelle situation vous préparez avant que quelqu’un accepte l’offre.

Que signifie l’annonce de Microsoft sur Rust pour votre équipe ?

Adopter un langage suppose aussi de prévoir les moyens de l’utiliser. L’annonce d’une grande entreprise invite à examiner vos propres méthodes de développement, sans pour autant copier ses critères de recrutement.

Dans un billet publié le 10 septembre par la Rust Foundation, Victor Ciura, ingénieur principal chez Microsoft, décrit le statut interne Tier-1 de Rust à travers les chaînes de compilation, les outils de développement, les processus qualité, l’intégration aux plateformes et le suivi en production. Il précise aussi que C++ reste dominant en interne. Il s’agit d’une classification propre à Microsoft, distincte des niveaux de prise en charge des plateformes cibles de Rust, et non d’une consigne de réécrire tous les projets. Rust Foundation : Rust devient un langage Tier-1 chez Microsoft

Pour une startup, la question utile est plus précise : que doit savoir faire un ingénieur dans le composant que vous comptez développer ? Enrichir un service existant ne demande pas le même travail que concevoir votre première bibliothèque Rust et décider comment les futurs contributeurs devront l’utiliser.

Le plan qui suit propose une démarche de management, pas un résultat mesuré sur l’efficacité du recrutement. Il aide à distinguer les compétences à acquérir des responsabilités qui exigent déjà de l’expérience. Adaptez les exercices et les exigences de revue à votre système : réussir ces exemples ne suffit pas à établir une aptitude à intervenir en production.

Déterminez les compétences Rust nécessaires dès l’arrivée

Fixez vos exigences à partir du travail à réaliser et des compétences et du temps disponibles pour le relire. Partez d’une modification concrète dont la nouvelle recrue serait responsable, puis précisez où un relecteur pourrait l’aider et où une expertise autonome est indispensable.

Pour chaque responsabilité, notez les conséquences d’une erreur. Modifier le message d’erreur d’un analyseur, concevoir des interfaces partagées et maintenir une interface entre langages ne justifient pas les mêmes exigences au seul motif que ces tâches utilisent Rust.

Cette distinction peut servir de point de départ à une discussion de recrutement :

Considérez ces lignes comme des pistes de discussion, pas comme une classification universelle des postes. Un intitulé familier peut recouvrir des responsabilités très différentes. Demandez au responsable du recrutement et à l’ingénieur qui relira le travail de s’accorder sur la situation qui décrit le poste.

Le cas le plus difficile est celui d’une équipe sans relecteur compétent en Rust. Inscrire quelqu’un à un cours ne crée pas cette capacité de revue. Il peut être nécessaire de recruter une personne expérimentée, de faire appel à un spécialiste externe avec une mission précise ou de reporter le développement du composant. « Nous apprendrons ensemble » ne dispense pas de décider qui approuvera la première modification importante.

Rendez ensuite l’offre d’emploi fidèle à la réalité. Si Rust peut s’apprendre dans le poste, dites-le et décrivez l’accompagnement. Si la personne doit guider les autres dès son arrivée, précisez les décisions dont elle sera responsable. Le guide Kit sur la définition du profil de candidat idéal aide à traduire ces responsabilités en critères observables avant les entretiens.

Donnez à chaque ingénieur un point de départ fonctionnel

Un guide d’installation utile se termine par une tâche qui fonctionne et le nom d’une personne à contacter. Documentez l’environnement réellement attendu par le dépôt, puis demandez à quelqu’un qui ne connaît pas le projet de suivre les instructions.

La documentation rustup décrit les fichiers de configuration de la chaîne de compilation et la commande rustup show, qui permet d’examiner la chaîne active. Des réglages prioritaires peuvent s’appliquer : la présence d’un fichier dans le dépôt ne suffit donc pas à savoir quelle chaîne une personne utilise. Comparez l’environnement actif à celui attendu par le projet. Manuel rustup : priorités de configuration

Le manifeste de dépendances et le fichier de verrouillage de Cargo remplissent des fonctions différentes. Le manifeste décrit les dépendances ; le fichier de verrouillage consigne les versions retenues après résolution. Cela aide à retrouver la même sélection de dépendances, sans garantir des bibliothèques système identiques, des dépendances sûres ou une compilation reproductible à l’octet près. Manuel Cargo : Cargo.toml et Cargo.lock

Reliez ces principes au dépôt dans les instructions d’intégration. Indiquez la configuration de la chaîne de compilation, les outils nécessaires sur la machine, les accès requis, le répertoire de travail et la commande exacte pour lancer un petit test existant. Précisez aussi les paramètres locaux à obtenir par la procédure habituelle d’attribution des accès. Le guide ne doit pas supposer que la nouvelle recrue sait déjà quel collègue détient l’information manquante.

Décrivez le résultat attendu sans vous appuyer sur une ancienne capture de terminal. Nommez le test ou le comportement que l’ingénieur doit observer. Si la commande échoue, indiquez les informations de diagnostic permettant de distinguer une dépendance absente d’une défaillance de l’application.

Désignez une personne chargée de tenir ces instructions à jour lorsque les méthodes de travail évoluent. Un échec d’installation peut révéler un défaut de documentation plutôt qu’un manque de compétences. Notez l’étape manquante tant qu’elle est encore claire et corrigez le guide avant la prochaine arrivée.

Enfin, montrez où cette même vérification s’exécute en intégration continue, ou CI. Demandez à l’ingénieur de retrouver un résultat récent et d’expliquer ce qui est vérifié. Vous reliez ainsi une commande locale au processus de revue de l’équipe. La discussion suivante peut partir d’une question concrète : quels éléments un relecteur attendrait-il pour examiner une modification proposée ?

Évaluez une petite modification que vous pouvez vraiment relire

Appuyez-vous sur un exercice circonscrit et des critères annoncés pour discuter du raisonnement. Si le poste accepte des personnes qui apprennent Rust, fournissez assez de contexte pour distinguer la méconnaissance du langage des aptitudes que vous cherchez à évaluer.

Prenez cet exercice fictif : un composant Rust fourni lit des données d’entrée et renvoie un résultat après analyse. Un champ mal formé produit actuellement une erreur peu utile. Demandez à l’ingénieur de modifier ce comportement, d’ajouter un test de régression et d’expliquer son choix. Fournissez un dépôt qui compile et décrivez le comportement attendu par le code appelant.

Cet exercice est un exemple à adapter, pas un indicateur validé de la performance au travail. Choisissez une petite tâche que les évaluateurs comprennent assez bien pour discuter d’autres solutions. N’utilisez pas un exercice de recrutement pour obtenir gratuitement du travail destiné à la production.

Rédigez les consignes avant d’inviter les candidats

Expliquez le comportement demandé, ce qui sort du périmètre et l’effort attendu. Précisez si la documentation, les recherches, l’assistance de l’IA et les échanges avec un relecteur sont autorisés. Demandez aux candidats de décrire les aides importantes utilisées, pour que la discussion qui suit reste cohérente avec les conditions annoncées.

Pour un poste ouvert à l’apprentissage, indiquez les points d’entrée pertinents et autorisez les questions. Dites si vous attendez une implémentation terminée, une tentative partielle argumentée ou les deux. Ces choix influencent la répartition de l’effort : ils doivent figurer dans les consignes, et non rester dans les attentes implicites des évaluateurs.

La documentation Cargo explique que cargo test compile et exécute les tests, notamment unitaires, d’intégration et de documentation. Son comportement dépend des options et de la configuration du projet. Demandez au candidat de nommer les vérifications exécutées et d’en expliquer la portée. Un résultat positif ne renseigne que sur les comportements couverts. Manuel Cargo : cargo test

Discutez des décisions avec les mêmes critères

La grille proposée aux évaluateurs peut rester courte :

• Comportement : la modification répond-elle à la demande, y compris pour l’entrée mal formée ?
• Tests : le test de régression reproduit-il le problème et exprime-t-il clairement le comportement attendu ?
• Explication : le candidat peut-il décrire la circulation des données et justifier la gestion des erreurs ?
• Périmètre : identifie-t-il les hypothèses et le travail volontairement laissé hors de l’exercice ?
• Revue : sait-il examiner une objection concrète et expliquer si elle modifie son approche ?

Consignez une observation pour chaque critère. « A expliqué pourquoi le code appelant a besoin du nom du champ » éclaire mieux la décision que « communique bien ». Si un évaluateur veut noter des choix de conception Rust avancés, vérifiez qu’ils faisaient bien partie du poste annoncé.

Notre guide pour structurer les exercices de code traite de l’expérience proposée aux candidats. Distinguez cet exercice de l’intégration d’un salarié : le candidat doit comprendre l’évaluation qu’il accepte, tandis que le salarié a besoin de temps et d’accompagnement pour apprendre le système de l’équipe.

Enseignez Rust à partir de votre propre base de code

Associez les supports de formation à un petit extrait de code que l’ingénieur peut expliquer à un relecteur. Choisissez les notions nécessaires à sa prochaine contribution accompagnée, sans transformer le programme d’un cours en liste de conditions pour une mise en production.

Le Rust Book présente la propriété comme un ensemble de règles de gestion de la mémoire vérifiées par le compilateur. Il explique les déplacements, les emprunts et ce qui se passe lorsqu’un propriétaire sort de portée. Ces notions permettent d’engager une discussion précise sur les données qui traversent le composant. Rust Book : qu’est-ce que la propriété ?

Choisissez par exemple une courte fonction qui renvoie des données au code appelant. Demandez à l’ingénieur d’en retracer l’origine, d’identifier leur propriétaire à chaque étape et d’expliquer pourquoi l’interface renvoie des données empruntées ou possédées. Discutez du caractère intentionnel d’une copie et de ce qu’une autre solution changerait. Limitez l’exercice pour que le relecteur puisse examiner le raisonnement, au lieu de simplement approuver les modifications.

L’équipe Android de Google publie Comprehensive Rust, une formation gratuite accessible sans connaissance préalable de Rust. Vous pouvez choisir les leçons pertinentes pour préparer cette discussion. Terminer un cours, ou suivre son calendrier, ne démontre pas une aptitude à prendre en charge votre composant en production.

Un parcours d’intégration peut suivre cette séquence :

1. Compiler : suivre le guide d’installation et retrouver le résultat du test attendu. Noter ce que les instructions n’expliquaient pas.
2. Expliquer : parcourir avec un relecteur un flux de données existant, un chemin d’erreur et une limite de propriété.
3. Modifier : proposer une modification de comportement circonscrite, expliquer les tests et répondre aux remarques de revue.
4. Exploiter : examiner le diagnostic, la mise en production et le retour à une version antérieure du composant réel, au niveau de responsabilité du poste.

Adaptez le rythme au travail et à l’accompagnement disponibles. Un calendrier fixe peut aider à organiser les échanges, mais une date ne prouve pas qu’une personne peut assumer une responsabilité avec les précautions nécessaires.

À chaque étape, notez brièvement ce qui a été observé et l’aide encore nécessaire. « Peut modifier cet analyseur avec une revue ; n’a pas encore pris en charge une mise en production » donne un contexte utile au prochain relecteur. Une étiquette comme « formé à Rust » efface cette distinction.

Laissez aussi l’ingénieur remettre les supports en question. Si l’exercice repose sur une convention non documentée, complétez la leçon. Si la tâche suivante exige une notion que le cours ne couvrait pas, prévoyez une explication ciblée avant de la confier.

Définissez ce qui exige une revue par un spécialiste de Rust

Identifiez les modifications qui demandent un jugement spécialisé avant qu’une nouvelle recrue les rencontre. Le plan de revue doit préciser qui peut les approuver et quoi faire lorsque cette personne est indisponible.

Le Rust Book explique que les opérations unsafe comportent des obligations que le programmeur doit respecter. Un bloc unsafe ne désactive pas le vérificateur d’emprunts, et le livre recommande de limiter ces blocs et de proposer des abstractions sûres. La compilation ne suffit pas à remplir ces obligations. Rust Book : Rust unsafe

Dans votre composant, repérez le code unsafe et les interfaces avec d’autres langages. Documentez les hypothèses que le relecteur doit vérifier. Une première contribution ne doit pas imposer implicitement à une personne en apprentissage de garantir seule la validité d’une abstraction qu’elle connaît mal.

Ne limitez pas les questions de revue à la gestion de la mémoire. L’ingénieur doit aussi raisonner sur le comportement demandé, les chemins d’erreur, les règles d’accès lorsqu’elles s’appliquent et la manière dont une modification parvient aux utilisateurs. Les vérifications du langage ne disent pas si l’implémentation répond au besoin produit.

Précisez les responsabilités que la personne peut désormais assumer. Vous pouvez autoriser des modifications accompagnées dans un module connu tout en réservant la conception des interfaces ou les mises en production à une personne expérimentée. Consignez ce périmètre et réexaminez-le après d’autres observations. Ne transformez pas un résultat de quiz en autorisation générale de maintenir tout le système.

Si le relecteur nécessaire est constamment indisponible, revoyez la charge de travail ou l’organisation de l’équipe. Une accumulation de revues bloquées est un problème de capacité que le responsable doit résoudre. Proposer un autre cours à la personne en apprentissage ne dit pas qui examinera sa prochaine modification.

Gardez des éléments de recrutement et de formation utiles dans Kit

Rendez les critères d’évaluation, les traces de formation et les décisions de revue technique assez explicites pour la personne suivante. Ils répondent à des questions différentes, même lorsqu’ils concernent le même langage.

Les étapes de recrutement de Kit permettent de définir des critères d’évaluation avec un nom, une description, un poids et une échelle. Les évaluateurs peuvent consigner des notes et des commentaires, et les exercices de code proposent des modèles GitHub et des consignes écrites. Ces fonctions organisent le recrutement autour des critères choisis. Elles ne prouvent pas qu’une implémentation soumise est correcte sans revue adaptée.

Pour la formation des salariés, Kit Training propose des cours rédigés par votre équipe avec diapositives, quiz et attestations, ainsi que des invitations, un suivi de progression et des rappels. Les programmes sous forme de listes de contrôle comportent des étapes modifiables, des instructions propres aux plateformes et des dépôts de preuves. Vous fournissez le contenu Rust et décidez de ce qu’une confirmation d’installation doit documenter ; Kit ne comprend pas de programme Rust et ne vérifie pas automatiquement les compétences en programmation.

Une trace de fin de formation indique que les étapes configurées ont été réalisées. Gardez le jugement technique explicite : qui a relu le travail, ce qui a été observé et quelle responsabilité l’ingénieur peut prendre ensuite. Terminer un cours ne remplace pas cet échange.

Avant de rendre Rust obligatoire dans une offre d’emploi, accordez-vous sur la première contribution, son relecteur et l’expertise réellement nécessaire au poste. Alignez ensuite les consignes de recrutement et les supports d’intégration sur cette décision. Vous disposerez d’un plan concret à discuter avec un candidat et un nouveau collègue.