Pourquoi ces erreurs sont difficiles à voir
Le code suggéré est syntaxiquement correct, bien indenté, nommé de façon cohérente. Il ressemble exactement à du code qui marche.
C'est précisément ce qui rend sa relecture piégeuse : notre attention se relâche devant du code qui a l'air propre. Les erreurs de l'autocomplétion ne sont pas des fautes de frappe, ce sont des erreurs de contexte.
Les six familles, par fréquence
Le cas limite oublié. La liste vide, la valeur nulle, la division par zéro, la chaîne à zéro caractère. La suggestion traite le cas nominal, qui est ce qu'elle a le plus vu.
La fonction plausible qui n'existe pas. Une méthode au nom parfaitement crédible, absente de la bibliothèque que vous utilisez, ou présente dans une autre version. Le compilateur l'attrape dans un langage typé, l'exécution seulement ailleurs.
Le mélange de versions. Un motif valable dans la version précédente de la bibliothèque, obsolète dans la vôtre. Le code fonctionne, avec un avertissement que personne ne lit.
L'erreur avalée. Un bloc de capture d'exception vide, ou qui journalise sans traiter. La panne devient silencieuse, ce qui est pire que la panne.
L'inefficacité invisible. Une requête dans une boucle, une lecture de fichier répétée. Rien ne se voit sur trois éléments de test, tout se voit sur dix mille en production.
La sécurité approximative. Une concaténation dans une requête plutôt qu'un paramètre, une vérification d'autorisation absente parce qu'elle n'était pas dans le contexte visible.
Trois questions avant d'accepter
Elles prennent dix secondes et attrapent l'essentiel.
Est-ce que je saurais l'écrire ? Si non, ne l'acceptez pas maintenant : lisez d'abord ce que fait chaque ligne. Du code non compris devient de la dette dès sa validation.
Que se passe-t-il si l'entrée est vide, nulle, ou énorme ? La question qui trouve la première famille d'erreurs.
Est-ce que ça touche des données ou des droits ? Si oui, la relecture n'est plus optionnelle et mérite un regard extérieur.
Le piège du volume
Accepter beaucoup de suggestions donne une sensation de vitesse réelle. Le travail se déplace : moins d'écriture, plus de relecture, et le total ne baisse que si la relecture est efficace.
Un signal fiable d'usage devenu contre-productif : vous acceptez plus vite que vous ne lisez. Le rythme d'écriture augmente, celui de compréhension non, et l'écart se paie au débogage.
Ce que l'autocomplétion fait très bien
Il serait malhonnête de ne lister que les risques. Elle excelle sur le code répétitif et vérifiable d'un coup d'oeil : structures de données, conversions, tests unitaires à partir d'une fonction existante, documentation d'une fonction écrite.
Sur ces usages, le gain est net et le risque faible, parce que l'erreur se voit immédiatement.
À retenir
Les erreurs ne sont pas syntaxiques mais contextuelles : cas limites, versions, erreurs avalées, requêtes en boucle. Trois questions avant d'accepter, dont « saurais-je l'écrire ». Et si vous acceptez plus vite que vous ne lisez, vous accumulez de la dette.