Introduction : La douleur familière de tout développeur TypeScript
\n\nVous écrivez du code en TypeScript, tout semble logique, mais soudain le compilateur affiche une erreur : Object is possibly 'null' ou Object is possibly 'undefined'. Familier ? Et comment ! C'est l'un des « maux de tête » les plus fréquents lors du passage de JavaScript à TypeScript. Et c'est là qu'intervient un symbole mystérieux — le point d'exclamation (!), aussi appelé opérateur bang ou, officiellement, opérateur d'assertion non-null.
Dans cet article, nous allons voir ce qu'est cette bête, comment et quand l'utiliser, et surtout — quand il ne faut pas l'utiliser. Nous examinerons les bonnes pratiques de 2025 pour que votre code soit non seulement fonctionnel, mais aussi sûr. C'est parti !
\n\nQu'est-ce que l'opérateur ! (bang) en TypeScript ?
\n\nL'opérateur ! (point d'exclamation) en TypeScript est un opérateur d'assertion non-null. Il dit au compilateur : « Hé, je sais avec certitude que cette valeur n'est ni null ni undefined, même si le type le permet. Désactive la vérification ici, s'il te plaît ».
En d'autres termes, c'est une assertion, et non un opérateur au sens classique (comme + ou -). Il n'exécute aucun code lors de l'exécution — c'est purement une indication pour TypeScript au moment de la compilation.
Exemple simple
\n\n// Fonction qui peut retourner null\nfunction findUser(id: number): User | null {\n // ... recherche dans la base de données\n return Math.random() > 0.5 ? { name: 'Alice' } : null;\n}\n\nconst user = findUser(1);\n\n// Sans ! — erreur de compilation\n// console.log(user.name); // ❌ Object is possibly 'null'\n\n// Avec ! — nous disons au compilateur : « Ne t'inquiète pas, je sais ce que je fais »\nconsole.log(user!.name); // ✅ Ok, mais dangereux !\n\n\nDans cet exemple, user!.name signifie : « Moi, développeur, je garantis que user n'est pas null. Compilateur, ne vérifie pas ». Si lors de l'exécution user s'avère être null, vous obtiendrez une erreur d'exécution (Cannot read properties of null).
Quand utiliser ! — bonnes pratiques 2025
\n\nDans la communauté TypeScript, un avis clair s'est dégagé : utilisez ! uniquement lorsque vous êtes sûr à 100 % que la valeur n'est pas null/undefined, et que le compilateur ne peut pas le prouver. Voici des scénarios réels.
\n\n1. Éléments DOM qui existent avec certitude
\n\nC'est le cas le plus courant et le moins dangereux. Si vous savez avec certitude que l'élément est présent dans le HTML, vous pouvez utiliser !.
const button = document.getElementById('submit-btn')!;\nbutton.addEventListener('click', () => {\n console.log('Clicked!');\n});\n\n\nPourquoi c'est acceptable ? Parce que si l'élément n'existe pas, votre application plantera de toute façon à la ligne suivante. Mais vous êtes sûr qu'il existe. L'alternative — la vérification if (button) — ajoute une imbrication inutile.
2. Initialisation dans le constructeur (classes Angular/React)
\n\nDans les classes où une propriété est initialisée plus tard (par exemple, via ngOnInit dans Angular), vous pouvez utiliser ! pour déclarer la propriété sans l'initialiser.
class MyComponent {\n data!: string[]; // Promesse qu'elle sera initialisée avant utilisation\n\n ngOnInit() {\n this.data = ['a', 'b', 'c'];\n }\n\n process() {\n // this.data n'est certainement pas undefined ici\n console.log(this.data.length);\n }\n}\n\n\nAttention : c'est toujours risqué. Si ngOnInit n'est pas appelé (par exemple, un bug), vous obtiendrez une erreur. En 2025, beaucoup préfèrent l'assertion d'affectation définie (! dans la déclaration) ou utilisent undefined comme valeur initiale.