Quand un taux de réussite de 96 % cache en réalité une compréhension proche de zéro
Un professeur d'économie de l'Université Brown (États-Unis) a récemment vécu une expérience qui devrait interpeller tout manager ou recruteur tech : ses étudiants ont obtenu une moyenne de 96 % sur un examen à la maison... avant de s'effondrer à 48 % lors d'un examen surveillé en présentiel. La majorité avait utilisé l'IA pour répondre — sans réellement comprendre les concepts sous-jacents.
Ce cas, relayé par The Decoder, n'est pas anecdotique. Deux études indépendantes confirment le même schéma : là où les étudiants s'appuient sur l'IA pour les devoirs non surveillés, leurs performances chutent drastiquement dès qu'ils sont seuls face à un problème. Le parallèle avec le monde du développement logiciel est direct — et préoccupant.
Le débogage sans filet : ce que l'IA ne peut pas faire à votre place
En développement PHP/Symfony, il est aujourd'hui possible de générer un contrôleur, une entité Doctrine ou une configuration de service en quelques secondes avec ChatGPT ou GitHub Copilot. Le code produit est souvent syntaxiquement correct, parfois même élégant. Mais que se passe-t-il quand ce code arrive en production et que quelque chose ne fonctionne pas comme prévu ?
C'est là que la fracture apparaît. Comprendre pourquoi un service n'est pas injecté correctement dans le conteneur Symfony, pourquoi une requête Doctrine génère un produit cartésien inattendu, ou pourquoi un event subscriber ne se déclenche pas dans le bon ordre — ces diagnostics exigent une connaissance intime du framework, pas une capacité à reformuler une question.
// L'IA peut générer ce code facilement
#[Route('/api/orders', name: 'api_orders_list')]
public function list(OrderRepository $repository): JsonResponse
{
return $this->json($repository->findActiveOrders());
}
// Mais comprendre POURQUOI findActiveOrders() génère un N+1
// et comment l'optimiser avec un JOIN ou un batch... c'est une autre histoire.
La maîtrise technique réelle, c'est ce qui reste quand on retire l'assistant IA de l'équation.
Ce que ça change concrètement pour le recrutement et le management tech
Si vous recrutez des développeurs PHP ou Symfony, ou si vous managez une équipe qui utilise l'IA au quotidien, l'expérience de Brown pointe vers un risque concret : évaluer des livrables générés par IA plutôt que la compétence réelle du candidat ou du collaborateur.
Quelques signaux d'alerte à surveiller :
- Un candidat produit un code impeccable en exercice libre, mais peine à expliquer ses choix lors d'une revue technique orale.
- Un développeur résout vite les tickets simples, mais bloque sur les anomalies complexes qui nécessitent de lire une stacktrace, d'inspecter le profiler Symfony ou de comprendre le cycle de vie d'une requête HTTP.
- Les estimations sont systématiquement optimistes, parce que l'IA donne l'illusion que tout est simple... jusqu'à ce que le contexte métier ou l'architecture existante résiste.
Cela ne signifie pas qu'il faut bannir l'IA des processus de recrutement ou des pratiques d'équipe — bien au contraire. Mais cela impose de séparer l'évaluation de la productivité assistée de l'évaluation de la compréhension fondamentale.
Adapter ses entretiens techniques à la réalité de l'IA
Concrètement, voici des ajustements pragmatiques pour valider l'expertise réelle :
- Privilegier les questions de type "pourquoi" et "que se passe-t-il si" plutôt que "écrivez ce code" : Pourquoi Symfony compile-t-il le conteneur ? Que se passe-t-il si vous injectez un service de scope "request" dans un service singleton ?
- Organiser des revues de code à voix haute : demander au candidat d'expliquer un extrait de code existant, d'identifier des problèmes potentiels, de proposer des améliorations.
- Tester la réaction face à l'erreur : soumettre un bug intentionnel dans un contexte Symfony et observer la démarche de diagnostic, pas juste le résultat.
- Poser des questions sur les compromis : Dans quel cas choisiriez-vous un message Messenger synchrone plutôt qu'asynchrone ? Quels sont les impacts sur la testabilité ?
Ces questions ne peuvent pas être déléguées à un LLM sans que la délégation elle-même ne soit évidente.
L'IA comme multiplicateur — pas comme substitut
L'enjeu n'est pas d'opposer IA et compétence. Les meilleurs développeurs de nos équipes utilisent l'IA quotidiennement — et c'est une force. Ils s'en servent pour aller plus vite sur le code répétitif, explorer des approches alternatives, rédiger des tests unitaires ou de la documentation. Mais ils savent exactement pourquoi le code généré fonctionne, et surtout quand il ne faut pas lui faire confiance.
C'est précisément cette capacité critique — savoir lire, questionner et corriger ce que l'IA produit — qui distingue un développeur senior d'un utilisateur avancé de ChatGPT.
Dans un contexte PHP/Symfony, cela se traduit par :
- Comprendre le cycle de vie des requêtes et du kernel HTTP.
- Savoir lire et interpréter le Profiler et le debug toolbar.
- Maîtriser les concepts de service container, de compiler passes et de décorateurs.
- Être à l'aise avec les migrations Doctrine, les transactions et les locks.
Aucun de ces sujets ne s'acquiert en copiant des réponses d'IA. Ils s'acquièrent en cassant des choses, en lisant des logs, en comprenant des erreurs.
Conclusion : recruter et former pour l'après-IA, pas pour l'IA
L'expérience du professeur Serrano est un miroir que le monde tech devrait s'approprier. La question n'est pas "est-ce que ce développeur utilise l'IA ?" — la réponse devrait être oui. La vraie question est : "que reste-t-il de ses compétences quand on retire l'outil ?"
Pour les recruteurs et les managers, cela implique de revoir les grilles d'évaluation, de valoriser la capacité d'explication et de raisonnement face à l'exécution pure, et de créer des environnements où apprendre par l'erreur reste possible — sans que l'IA ne court-circuite systématiquement ce processus d'apprentissage.
L'IA est un accélérateur remarquable. Mais les fondamentaux, eux, restent le moteur.
