Pour aller droit au but, une regex simple permet de valider 2 formats précis de numéro américain à 10 chiffres, xxx-xxx-xxxx et (xxx)xxx-xxxx. La forme la plus propre ressemble à ^(\d{3}-\d{3}-\d{4}|\(\d{3}\)\d{3}-\d{4})$, avec 10 chiffres au total et un contrôle strict du début à la fin.
La regex qui fait le job, sans surprise
Le besoin de départ est très classique en développement, accepter soit un numéro écrit avec des tirets, soit un indicatif entouré de parenthèses. En clair, il faut autoriser 123-456-7890 et (123)456-7890. L’idée clé est d’utiliser une alternance, c’est-à-dire un ou logique dans la regex. Le premier bloc, \d{3}-\d{3}-\d{4}, vérifie trois chiffres, un tiret, trois chiffres, un tiret, puis quatre chiffres. Le second bloc, \(\d{3}\)\d{3}-\d{4}, impose des parenthèses autour des trois premiers chiffres avant la suite du numéro. Les ancres ^ et $ sont essentielles, car elles forcent la chaîne entière à respecter le format, sans caractères parasites avant ou après.
Le piège classique, accepter plus que prévu
Sur Stack Overflow, le point intéressant vient d’un détail souvent oublié, une regex peut sembler correcte tout en laissant passer des formats bizarres. Par exemple, certaines versions trop souples peuvent aussi accepter quelque chose comme xxx-(xxx)xxx-xxxx. Techniquement, la regex correspond, mais ce format n’était pas demandé. C’est tout le cœur du sujet en validation, il ne faut pas seulement faire matcher des cas valides, il faut aussi refuser les cas non prévus. Quand on écrit une expression régulière, chaque parenthèse optionnelle ou séparateur facultatif peut élargir le résultat plus qu’on ne le pense. Le bon réflexe consiste donc à partir de formats très clairement définis, puis à écrire une expression aussi précise que possible.
Ce que ça change en vrai pour tes formulaires
Dans un formulaire, une validation trop permissive crée de la donnée sale, et une validation trop stricte frustre les utilisateurs. Ici, tout dépend du besoin produit. Si tu veux seulement 2 formats exacts, la regex ci-dessus est adaptée. Si tu veux aussi autoriser des espaces, un code pays ou d’autres variantes, il faut le décider dès le départ au lieu de bricoler après coup. En bonus, pense à séparer validation et affichage, car un numéro peut être stocké en chiffres bruts puis formaté joliment côté interface. Et toi, dans tes projets, tu préfères une saisie très libre ou un format verrouillé dès le premier champ ?