« Combien d’années d’expérience sur cette technologie ? »
Je connais mes projets, les problèmes résolus et les responsabilités assumées. Pourtant, au moment de donner un chiffre, j’hésite.
Dois-je compter depuis mes débuts, retenir certaines missions, retrancher les interruptions ?
Ma réponse dépend d’une règle que la question ne précise pas.
Depuis quand je pratique, ou combien de temps j’y ai consacré ?
Mes débuts en PHP remontent à 1999. Cela ne représente pas vingt-sept ans de pratique exclusive.
Je travaillais notamment sur une stack LAMP : Linux, Apache, MySQL et PHP. Développement, base de données et déploiement contribuaient au même résultat. Une année sur cet ensemble ne devient ni une année à temps plein sur chaque composante, ni quatre parts égales.
Je peux expliquer mes projets et mes responsabilités. Isoler rétrospectivement mes heures de PHP serait une estimation.
Le problème concerne aussi les frameworks : pratiquer Symfony ou Spring Boot ponctuellement pendant trois ans ne décrit pas la même activité qu’un usage quotidien.
Compter depuis la première utilisation ou retenir certaines missions produit des réponses différentes. Sans règle explicitée, un candidat prudent peut annoncer moins d’années qu’un autre ayant une pratique comparable.
Que cherche-t-on derrière les années ?
Avant de choisir comment compter, il faut comprendre ce que ce nombre est censé indiquer. Je retiens trois hypothèses, à confronter aux recruteurs :
- Une autonomie attendue : confier certaines tâches avec un niveau d’accompagnement donné.
- Des situations déjà rencontrées : maintenance, migrations, incidents ou suivi d’un système après sa livraison.
- Un critère de tri : réduire les candidatures ou respecter une exigence du client.
Ces attentes peuvent se combiner. La durée conserve un intérêt : suivre un système permet d’observer les conséquences de ses décisions. Mais elle ne décrit pas automatiquement ce qu’on sait prendre en charge.
Pour éclairer ce qu’on attend du candidat, une question me paraît utile :
Quand vous demandez trois ans d’expérience, quelles compétences recherchez-vous concrètement ?
L’IA rend le périmètre encore plus important
Cette question se pose aussi pour l’IA, qui recouvre des activités très différentes.
Une annonce SQLI de Data Scientist IA générative, consultée le 6 novembre 2026, demande au moins trois ans d’expérience sur des sujets d’IA générative. C’est un exemple, pas une représentation de tout le marché.
Utiliser un assistant, intégrer un modèle à une application ou l’entraîner demande pourtant des compétences différentes. Les regrouper sous « trois ans d’IA » ne les rend pas équivalentes.
Dans le développement assisté par IA, obtenir du code ne démontre pas qu’on sait l’évaluer. GitHub rappelle ainsi que les suggestions de Copilot doivent être revues et validées par l’utilisateur.
La durée n’a donc de sens qu’une fois l’activité précisée.
Étayer sa pratique sans tout chronométrer
Je peux situer une période, décrire les tâches prises en charge et les relier à un projet concret. La conception et le diagnostic comptent aussi lorsqu’ils mobilisent réellement la technologie concernée.
Des outils de suivi d’activité comme WakaTime apportent des traces complémentaires. Les durées calculées dépendent des événements détectés et du réglage des pauses, comme l’explique sa documentation.
Ils documentent une partie de la pratique ; ils ne certifient ni toute l’expérience ni la maîtrise.
Même sans outil de suivi, des livrables, un historique de contributions ou des attestations de mission permettent de justifier son expérience, sans reconstituer toutes les heures.
Changer de technologie ne remet pas l’expérience à zéro
Ces traces ne disent pas encore comment tenir compte des compétences acquises ailleurs.
J’ai commencé à travailler sérieusement avec Spring Boot fin 2024. Face à un seuil de trois ans sur ce framework Java, je ne remplis pas le critère.
Pourtant, mon expérience en conception, en bases de données ou en diagnostic peut soutenir mon apprentissage. Elle ne prouve pas une expertise de Spring Boot : il faut examiner à la fois ma connaissance du framework et les acquis du métier.
Cette distinction concerne aussi la séniorité. Je proposerais des repères liés au travail confié :
- Junior : a besoin d’un accompagnement régulier sur ce périmètre.
- Confirmé : traite les situations courantes avec autonomie et sait quand demander de l’aide.
- Senior : prend aussi en charge des situations complexes, justifie ses arbitrages et aide les autres à progresser.
Ce sont des repères de lecture, pas une classification universelle.
Le référentiel de compétences professionnelles SFIA distingue lui aussi l’autonomie, l’influence, la complexité et les connaissances pour situer un niveau de responsabilité. Les repères proposés ici ne correspondent toutefois pas directement à ses niveaux.
Évaluer les compétences utiles au poste
Comment évaluer cette autonomie en entretien ? Demander « Êtes-vous à l’aise avec cette technologie ? » reste subjectif. Un test technique apporte d’autres éléments, à condition de porter sur ce que le poste exige.
Une question pointue peut être pertinente pour une mission d’expertise. Elle renseigne moins sur la capacité à livrer une solution si la particularité testée n’intervient pas dans le travail attendu.
Pour un généraliste comme moi, le risque est d’être évalué comme un spécialiste de chaque technologie que j’assemble.
Je comprends pourtant qu’une entreprise cherche à réduire le risque d’un recrutement. Lorsque je travaillais dans une fédération professionnelle, j’ai dû identifier des personnes capables de m’épauler sur une technologie.
Je posais des questions assez générales, avec une appréciation largement intuitive de leur maîtrise. Je cherchais aussi des acquis sur lesquels construire et une envie d’apprendre.
Cette approche souple a permis des collaborations concluantes. Elle ne rend pas mon intuition infaillible : la motivation ne remplace pas toutes les compétences nécessaires, surtout si la mission exige une autonomie immédiate.
Faire intervenir plusieurs personnes peut apporter des regards complémentaires. Encore faut-il s’accorder sur ce que chacune évalue. Connaître finement un outil ne garantit pas, à lui seul, la pertinence des critères retenus.
Je préférerais partir d’une réalisation :
- Quel besoin fallait-il résoudre ?
- Quel était le rôle du candidat ?
- Quels choix a-t-il faits ?
- Comment a-t-il vérifié le résultat ?
Les questions techniques peuvent ensuite éclairer ses décisions et ses limites, avec une profondeur adaptée au poste.
Vérifier les bonnes choses
Je pars d’une difficulté à compter mes années et j’aboutis à une question de recrutement : quelles compétences veut-on réellement vérifier ?
Les années et les tests apportent des indices. Ils ne dispensent pas de définir le travail à confier et l’autonomie nécessaire.
Côté candidat, je peux préciser depuis quand je pratique, dans quel contexte et ce que j’ai réalisé. Je distingue ma connaissance de la technologie, mes acquis du métier et ce que je dois encore apprendre.
Si un formulaire impose un nombre, je donne une estimation que je peux expliquer et j’en précise le contexte lorsque c’est possible.
Côté recrutement, quelles compétences sont indispensables dès l’arrivée, lesquelles peuvent s’apprendre et lesquelles compléteraient l’équipe ? Une lacune sur une particularité du framework est-elle réellement rédhibitoire pour la mission ?
Un généraliste doit pouvoir montrer son apport sans être supposé spécialiste de chaque composante. Un spécialiste doit pouvoir démontrer la profondeur attendue. Les limites méritent d’être explicitées, autant que les acquis.
L’enjeu n’est pas de rendre le recrutement plus facile, mais de vérifier les bonnes choses.
Encore faut-il que ces critères soient explicités lorsqu’une candidature est refusée. Sans retour concret, comment savoir si ce sont mes compétences, mon expérience ou une autre contrainte qui ont pesé dans la décision ?