Pourquoi les entreprises demandent-elles de l’expérience ? Elles ont peut-être une bonne raison
« Nous recherchons un profil avec deux, trois ou cinq ans d’expérience. »
Cette phrase fait légitimement grincer des dents.
Comment obtenir de l’expérience lorsque presque toutes les offres demandent déjà de l’expérience ? Comment un jeune diplômé peut-il entrer dans le monde professionnel si les entreprises privilégient systématiquement ceux qui y sont déjà entrés ?
Je comprends parfaitement cette frustration. Et je pense qu’il faut continuer à donner leur chance aux nouveaux entrants. Une entreprise ne devrait pas considérer l’absence d’expérience comme une absence de potentiel. Les jeunes profils peuvent avoir une capacité de réflexion remarquable, une grande curiosité, une capacité d’apprentissage parfois supérieure à celle de profils plus expérimentés et surtout une manière différente d’aborder les problèmes.
Mais avec le recul que donnent les projets réels, j’ai progressivement compris quelque chose : l’expérience n’est pas nécessairement ce qui rend quelqu’un plus compétent. Elle change surtout sa manière de penser les conséquences de ses décisions.
Et c’est probablement là que se trouve sa véritable valeur pour une entreprise.
L’expérience ne signifie pas nécessairement « savoir faire davantage »
Il existe une confusion assez fréquente autour de la notion d’expérience.
On imagine parfois qu’une personne expérimentée possède simplement davantage de compétences techniques qu’une personne débutante.
Ce n’est pas toujours vrai.
Un jeune développeur peut parfaitement maîtriser une technologie qu’un développeur senior connaît moins bien. Un jeune ingénieur peut proposer une solution plus élégante, plus moderne ou plus performante. Un nouveau diplômé peut parfois avoir une capacité de raisonnement, de recherche et d’apprentissage impressionnante.
L’expérience ne donne donc pas automatiquement une nouvelle compétence à l’entreprise.
Elle ne constitue pas non plus une preuve absolue d’une meilleure capacité de réflexion.
Alors, pourquoi les entreprises continuent-elles à accorder autant d’importance à l’expérience ?
Parce que dans un projet réel, le problème n’est presque jamais uniquement de savoir comment faire quelque chose aujourd’hui.
Le véritable problème est souvent :
Que va-t-il se passer lorsque le projet grandira ?
Avec les projets, on apprend progressivement à penser au-delà de la tâche
Lorsque l’on débute, on raisonne naturellement autour du problème qui se trouve devant nous.
On nous demande un formulaire ?
On réfléchit au formulaire.
On nous demande une page ?
On construit la page.
On nous demande une fonctionnalité ?
On implémente la fonctionnalité.
Et c’est parfaitement normal.
Au début, notre objectif principal est de produire quelque chose qui fonctionne.
Puis, à mesure que l’on travaille sur des projets plus importants, une autre réalité apparaît.
On découvre que les projets ne restent jamais tels qu’ils étaient le jour où ils ont été conçus.
Ils évoluent.
Les besoins changent.
Les utilisateurs demandent de nouvelles fonctionnalités.
Les règles métier évoluent.
Le design est modifié.
Une fonctionnalité qui était utilisée dans trois endroits se retrouve finalement utilisée dans trente.
Une donnée qui était auparavant facultative devient obligatoire.
Une logique qui semblait spécifique à un écran devient finalement commune à toute l’application.
Et c’est à ce moment que l’on commence réellement à comprendre pourquoi les entreprises accordent autant de valeur à l’expérience.
L’expérience apprend progressivement à anticiper les problèmes qui ne sont pas encore présents.
La véritable valeur de l’expérience : anticiper
À mes yeux, c’est probablement l’une des différences les plus importantes entre quelqu’un qui débute et quelqu’un qui a déjà vécu plusieurs cycles de projets.
Le junior demande souvent : « Comment puis-je résoudre ce problème ? »
L’expérimenté finit progressivement par ajouter une deuxième question : « Et qu’est-ce que cette décision va provoquer lorsque le projet évoluera ? »
Cette deuxième question change énormément de choses.
Elle pousse à réfléchir à la maintenance.
À la réutilisation.
À la scalabilité.
À la cohérence.
À l’évolution.
Aux futures modifications.
Aux risques.
Et surtout, elle pousse à ne pas seulement construire pour aujourd’hui, mais à construire en tenant compte de demain.
C’est une forme d’anticipation qui ne s’apprend pas uniquement dans les livres.
Elle se construit souvent après avoir rencontré plusieurs fois les mêmes problèmes.
Un projet sérieux n’est pas seulement un projet qui fonctionne
C’est ici que ma vision des projets a beaucoup évolué.
Lorsque l’on travaille sur un projet académique ou sur un petit prototype, faire fonctionner la solution peut constituer l’objectif principal.
Mais lorsqu’un logiciel est destiné à être réellement utilisé par des utilisateurs, le raisonnement doit changer.
Un projet sérieux doit pouvoir évoluer.
Il doit pouvoir être maintenu.
Il doit pouvoir absorber de nouveaux besoins.
Il doit pouvoir accueillir davantage d’utilisateurs, davantage de données ou davantage de fonctionnalités.
Autrement dit, une bonne solution ne doit pas seulement répondre au besoin actuel.
Elle doit également laisser suffisamment de liberté au projet pour répondre aux besoins futurs.
C’est là que trois notions deviennent particulièrement importantes.
1. La scalabilité
Que se passe-t-il lorsque le nombre d’utilisateurs augmente ?
Lorsque le nombre de fonctionnalités augmente ?
Lorsque plusieurs équipes commencent à travailler sur le même produit ?
Une solution qui fonctionne parfaitement avec dix utilisateurs peut devenir problématique avec dix mille.
2. La maintenabilité
Que se passe-t-il lorsqu’une partie du système doit être modifiée ?
Une modification doit-elle être effectuée à un seul endroit ou dans vingt fichiers différents ?
Une nouvelle personne qui rejoint le projet peut-elle comprendre rapidement l’organisation du système ?
La maintenance ne devrait pas être une chasse au trésor.
3. L’évolution
Que se passe-t-il lorsque les besoins changent ?
Parce qu’ils changeront.
Un logiciel qui ne peut pas évoluer facilement finit généralement par accumuler de la complexité.
Et cette complexité finit un jour par ralentir considérablement l’entreprise.
Prenons un exemple très simple : un formulaire
Prenons quelque chose qui peut sembler extrêmement banal : un formulaire dans une application web.
Un développeur débutant peut parfaitement produire un très bon formulaire.
Il peut réfléchir à :
une interface moderne ;
de beaux champs ;
des animations ;
une bonne expérience utilisateur ;
une validation correcte ;
une belle organisation visuelle.
Et ce travail peut être excellent.
Mais imaginons maintenant que le projet grandisse.
Au départ, il existe :
Trois formulaires.
Puis dix.
Puis trente.
Puis cinquante composants contenant des formulaires.
Quelques mois plus tard, l’entreprise décide de modifier le design.
La hauteur des champs doit changer.
Le style des bordures doit évoluer.
La typographie doit être harmonisée.
Le comportement sur mobile doit être corrigé.
Un nouveau mécanisme de validation doit être ajouté.
Dans une approche où chaque formulaire a été développé indépendamment, une simple évolution graphique peut devenir un véritable chantier.
Il faut rechercher les différents composants.
Identifier les différentes implémentations.
Modifier chaque formulaire.
Tester chaque écran.
Vérifier qu’aucun comportement n’a été cassé.
Et recommencer.
L’approche expérimentée commence à voir le problème avant qu’il existe
Un développeur plus expérimenté peut se poser une question différente dès le départ :
« Sommes-nous certains que nous n’aurons que deux ou trois formulaires dans cette application ? »
Probablement pas.
Il peut alors décider de créer un composant commun, par exemple un FormInput, qui servira de canevas aux différents formulaires de l’application.
L’objectif n’est pas simplement de gagner quelques lignes de code.
L’objectif est surtout de centraliser une décision qui risque d’être répétée de nombreuses fois.
Le jour où l’on veut modifier le design du formulaire, on modifie le composant central.
Et les différents écrans qui l’utilisent bénéficient automatiquement de cette évolution.
Ce qui aurait pu nécessiter la modification de cinquante composants devient potentiellement une modification à un seul endroit.
C’est là que l’on voit la différence entre : construire une fonctionnalité et concevoir un système capable d’accueillir des fonctionnalités.
Le senior ne pense pas forcément à une meilleure solution aujourd’hui
C’est un point important.
Il serait simpliste de dire :
« Le junior construit mal et le senior construit bien. »
La réalité est beaucoup plus nuancée. Le junior peut trouver une solution techniquement excellente. Le senior peut même parfois faire un choix moins élégant ou moins moderne. La différence ne se situe donc pas nécessairement dans la qualité immédiate de la solution. Elle se situe souvent dans la profondeur de l’horizon considéré.
Le junior peut optimiser pour : « Est-ce que cela fonctionne ? »
L’expérimenté finit par optimiser simultanément pour : « Est-ce que cela fonctionne ? »
mais aussi :
« Est-ce que cela restera compréhensible ? »
« Est-ce que cela pourra être réutilisé ? »
« Est-ce que cette décision pourra évoluer ? »
« Que se passera-t-il si cette fonctionnalité devient centrale dans l’application ? »
« Que se passera-t-il si demain une autre équipe doit travailler dessus ? »
« Combien coûtera cette décision à modifier dans six mois ? »
Cette dernière question est particulièrement importante.
L’expérience permet progressivement de mesurer le coût futur d’une décision présente.
Les erreurs deviennent une forme de capital
Il existe une autre dimension de l’expérience que l’on sous-estime souvent.
L’expérience, ce n’est pas uniquement le nombre d’années inscrites sur un CV.
C’est aussi le nombre de problèmes que l’on a déjà rencontrés.
Avoir déjà construit quelque chose qui est devenu difficile à maintenir.
Avoir déjà dupliqué une logique qui aurait dû être centralisée.
Avoir déjà choisi une architecture qui semblait adaptée mais qui a mal supporté la croissance.
Avoir déjà modifié trente fichiers pour une évolution qui aurait pu être faite dans un seul.
Avoir déjà découvert une dette technique plusieurs mois après une décision apparemment anodine.
Toutes ces expériences construisent progressivement une sorte d’intuition professionnelle.
On commence à reconnaître certains schémas.
On voit venir certains problèmes.
On identifie certaines décisions qui semblent rapides aujourd’hui mais qui seront coûteuses demain.
C’est probablement l’une des formes les plus précieuses de l’expérience.
C’est pourquoi l’expérience est si importante pour une entreprise
Une entreprise ne recrute pas uniquement quelqu’un pour produire du code, écrire des requêtes SQL, analyser des données, concevoir des interfaces ou développer des fonctionnalités.
Elle recrute également quelqu’un pour réduire l’incertitude.
Un professionnel expérimenté peut parfois dire :
« Cette solution fonctionne, mais je ne la recommande pas de cette manière parce que nous allons probablement rencontrer tel problème lorsque X arrivera. »
Cette capacité a une valeur considérable.
Parce que l’entreprise ne paie pas uniquement le temps nécessaire pour réaliser la tâche.
Elle investit aussi dans la capacité du professionnel à éviter certaines erreurs futures.
Et cela dépasse largement le domaine du développement logiciel.
Un architecte expérimenté pense à l’évolution d’un bâtiment. Un ingénieur expérimenté pense aux contraintes futures d’un système. Un data engineer expérimenté pense à la croissance des volumes et aux futurs usages de la donnée. Un product manager expérimenté pense aux conséquences d’une décision produit sur les prochains cycles. Un chercheur expérimenté pense à la manière dont une méthodologie pourra être reproduite, étendue et remise en question.
La logique reste la même : l’expérience élargit l’horizon de décision.
« Construire pour aujourd’hui est une compétence. Construire en sachant que demain sera différent est une maturité.»
Commentaires