Publié le 17 décembre 2025 14:55:00. Apprendre une nouvelle technologie passe souvent par l’échec, une étape essentielle pour comprendre ses limites et ses subtilités. Un expert en bases de données explique comment l’expérience de l’erreur est plus révélatrice que la simple maîtrise théorique, une leçon valable également pour l’intelligence artificielle.
- L’apprentissage d’une technologie est rarement linéaire et implique inévitablement des erreurs.
- L’expérience de l’échec permet de comprendre les compromis et les limites d’une technologie.
- Cette approche s’applique également aux nouveaux outils d’IA, où la capacité à identifier et corriger les erreurs est cruciale.
Il est courant de se sentir rapidement compétent lors de l’apprentissage d’une nouvelle technologie. Après quelques tutoriels et exemples simples, l’illusion de la maîtrise peut s’installer. Pourtant, cette confiance est souvent fragile et ne résiste pas à la confrontation avec des problèmes réels. C’est en se confrontant à l’échec, en analysant les causes des dysfonctionnements, que l’apprentissage devient véritablement significatif.
Lorsqu’il recrute, cet expert en bases de données pose une question inhabituelle aux candidats prétendant maîtriser les bases de données relationnelles :
« Parlez-moi du pire schéma de base de données que vous ayez jamais créé. Qu’est-ce que cela vous a appris à éviter ? »
Expert en bases de données
Il ne s’agit pas d’un piège, mais d’une manière de tester l’expérience pratique des candidats. La conception de bases de données est un exercice de compromis constant, où les exigences de performance transactionnelle doivent souvent être conciliées avec les besoins d’analyse et de reporting. Un schéma optimisé pour l’un peut se révéler inefficace pour l’autre. Il arrive ainsi qu’une optimisation initiale pour le reporting dégrade les performances des transactions, et vice versa.
Une réponse pertinente prend généralement la forme suivante :
« Nous avions conçu une base de données pour un débit transactionnel élevé. L’une des erreurs initiales a été de choisir MySQL. L’entreprise l’a ensuite utilisée pour des rapports, ce qui a créé des problèmes. Le système a évolué au fil des années, avec des jointures complexes, des index mal adaptés et des tâches nocturnes qui perturbaient le trafic des utilisateurs. Nous avons finalement dû séparer les réplicas en lecture, envisager un entrepôt de données, et après cinq ou six ans, simplifier les transactions et les migrer vers Cassandra. »
Témoignage d’un développeur
Cette expérience témoigne d’une compréhension profonde des compromis inhérents à la gestion d’une base de données. Même si cette personne ne maîtrise pas forcément les subtilités des algorithmes abordés lors des entretiens techniques, son expérience pratique est, aux yeux de cet expert, bien plus précieuse.
L’auteur de cet article se souvient d’un schéma transactionnel qu’il avait conçu, initialement jugé parfait sur le papier : normalisé, propre, chaque élément à sa place. Mais lorsque des analyses ont été demandées, avec la création de quelques tableaux de bord, le modèle 3NF s’est retrouvé transformé en une feuille de calcul géante, traitant un million de lignes pour un simple rapport comptable. Rapidement, la base de données a commencé à ralentir, passant 80 % de son temps à mettre à jour un index. La situation était d’autant plus délicate que le projet était sur le point d’être livré, rendant toute refonte complexe et coûteuse.
La solution envisagée, et qui témoigne d’un désespoir croissant, a été d’acheter des disques durs plus rapides, avec des IOPS (Input/Output Operations Per Second) plus élevés. Une approche qui ne faisait que masquer le problème de fond. L’auteur en a tiré plusieurs leçons : l’amélioration du matériel ne fait que retarder l’inévitable, la mise à l’échelle horizontale est incompatible avec les bases de données relationnelles, et il a découvert l’expression « plan de requête de l’enfer », qu’il a tenté de maîtriser avec des vues matérialisées et des réplicas en lecture, avant de finalement mettre en place un véritable système de reporting.
La leçon principale est de concevoir en fonction des besoins réels, et non des hypothèses. Il faut anticiper l’évolution des besoins et prévoir une certaine flexibilité.
Cette même logique s’applique aux nouveaux outils d’IA, comme les curseurs et les copilotes. L’auteur observe que de nombreux utilisateurs se vantent de la facilité d’utilisation de ces outils, mais il estime que ces témoignages en disent long sur les utilisateurs eux-mêmes. Ils ignorent souvent la réalité du processus, qui est rarement aussi simple et ludique qu’il y paraît. Même si ces outils permettent de réaliser des progrès rapides, ceux qui les utilisent réellement pour écrire du code sont les premiers à reconnaître qu’ils rencontrent de nombreuses difficultés.
L’apprentissage avec l’IA n’est pas « facile ». Il faut pousser l’outil jusqu’à ses limites, jusqu’à ce qu’il échoue. L’auteur cite quelques exemples de ses propres requêtes, formulées avec une certaine frustration : « Vous vous moquez de moi ? J’avais spécifié une règle interdisant cela, et vous l’avez ignorée ! »
Chaque fois qu’il voit des personnes s’enthousiasmer pour une nouvelle technologie, il se demande si elles l’ont réellement utilisée à fond. Si c’était le cas, elles comprendraient que ce n’est pas aussi simple qu’elles le prétendent.
Le développement de cette capacité à échouer et à apprendre de ses erreurs est essentiel, que ce soit dans le domaine des bases de données ou de l’intelligence artificielle. Il faut oser expérimenter, repousser les limites, et analyser les causes des échecs pour progresser. L’astuce n’est pas d’éviter l’échec, mais de l’accepter comme une opportunité d’apprentissage.
En conclusion, si vous n’avez jamais cassé quelque chose, vous ne le connaissez pas vraiment. Cela vaut pour le codage, la budgétisation, la gestion, la cuisine et le ski. Et la plupart des gens qui parlent de « vibe coding » n’ont pas encore eu cette expérience.
Les ingénieurs en qui l’auteur a le plus confiance sont ceux qui peuvent expliquer pourquoi quelque chose a échoué et comment ils ont ajusté leur approche. C’est le même principe qui s’applique aux outils de codage de l’IA. Plus vous pouvez exécuter rapidement la boucle (essayer → casser → inspecter → affiner), plus vous vous améliorerez.
À ne pas manquer
