Formatage Python - F-strings, format() ou % - Le bon choix ?

Le formatage en Python ne sert pas seulement à faire joli. Il influence la lisibilité des logs, la clarté des réponses d’API, la précision des rapports et la qualité des messages affichés à un utilisateur. Le besoin derrière python format est presque toujours le même : transformer une valeur brute en sortie claire, stable et adaptée au contexte. Je vais montrer comment choisir entre les f-strings, format() et l’ancien opérateur %, puis comment régler l’alignement, la précision, les dates et les données structurées sans perdre du temps.

Pourquoi le formatage en Python mérite d’être bien choisi

Quand j’analyse du code Python, je vois souvent le même arbitrage mal posé : on traite le formatage comme un détail alors qu’il touche directement à la maintenance. Un message de log mal construit, un export mal aligné ou un chiffre affiché avec une précision trompeuse peuvent coûter plus de temps qu’une petite fonction bien écrite.

Il faut aussi distinguer deux besoins. Le premier, c’est l’affichage humain : un texte lisible, des nombres compréhensibles, des dates cohérentes avec la cible. Le second, c’est la représentation technique : une sortie stable pour le débogage, le transport de données ou un traitement ultérieur. Ces deux besoins n’appellent pas toujours la même forme de formatage.

C’est précisément pour cela qu’il vaut mieux comparer les mécanismes avant d’écrire la première f-string. Une bonne décision au départ évite des retouches répétées plus tard, surtout dans un backend où les sorties servent à la fois au support, aux développeurs et parfois aux utilisateurs finaux.

Choisir la bonne méthode entre f-strings, format() et %

En 2026, ma règle est simple : je pars presque toujours sur les f-strings, puis je bascule vers une autre option seulement si le contexte l’exige. Ce n’est pas une question de mode, mais de lisibilité, de compatibilité et de souplesse.

Le point technique à retenir, c’est que format(value, spec) et les f-strings s’appuient sur le même protocole de fond : __format__. Autrement dit, un type peut décider lui-même comment il s’affiche selon un spécificateur donné. C’est très utile pour des objets métier, par exemple un prix, une durée ou un identifiant métier avec une présentation standardisée.

Je vois aussi un changement de fond sur les versions récentes de Python : la syntaxe des f-strings est devenue plus souple et plus robuste qu’à ses débuts. Résultat, elles restent le meilleur point d’entrée pour la plupart des projets, tant qu’on garde les expressions simples et lisibles. Une fois cette base posée, il devient beaucoup plus facile de lire la mini-langue de formatage.

Lire la mini-langue de formatage en pratique

Le cœur du sujet, ce sont les spécificateurs placés après les deux-points. La structure générale est simple : {valeur:options}. Derrière cette forme courte, Python permet de contrôler l’alignement, la largeur, le remplissage, la précision et le type de rendu.

Pour le débogage, j’utilise souvent aussi !r et la syntaxe =. f"{obj!r}" affiche la représentation de développement de l’objet, utile quand on veut voir la valeur exacte. f"{variable=}" accélère les logs de diagnostic sans écrire une chaîne entière à la main. Ce sont des détails, mais ils font gagner du temps dès qu’on enquête sur un bug.

Le vrai seuil de maîtrise, ce n’est pas de mémoriser toute la table. C’est de savoir reconnaître les trois besoins les plus fréquents : largeur, précision et type de rendu. Dès que ces trois points sont clairs, on peut passer du simple affichage au formatage utile, celui qui aide vraiment à lire une donnée.

Formater des nombres, des dates et des données structurées sans perdre en lisibilité

Le formatage d’un nombre n’est pas le même selon qu’il sert à un calcul interne, à un rapport ou à un écran utilisateur. Par exemple, une valeur monétaire supporte mal l’approximation implicite d’un float. Quand le montant compte vraiment, je préfère Decimal pour éviter les écarts de représentation qui se voient à la marge mais finissent par compter en production.

from decimal import Decimal

montant = Decimal("1234.50")
taux = Decimal("0.0375")

print(f"{montant:,.2f}")
print(f"{taux:.1%}")

Sur une interface destinée à la France, le point sensible n’est pas le calcul, mais la convention d’affichage. Python peut séparer les milliers et fixer une précision, mais il ne devine pas toujours le format local que vous voulez vraiment, par exemple une virgule décimale et une espace fine insécable. Pour du texte visible par un humain, je passe vite par une couche d’internationalisation ou par le module locale, avec prudence dans les applications web concurrentes, parce que cet état peut être global au processus.

Les dates demandent un autre réflexe. Là, le formatage repose souvent sur strftime ou sur le support intégré par datetime via format(). Les directives les plus utiles restent simples : %d pour le jour, %m pour le mois, %Y pour l’année, %H et %M pour l’heure et les minutes.

from datetime import datetime

now = datetime.now()
print(now.strftime("%d/%m/%Y %H:%M"))
print(f"{now:%d/%m/%Y %H:%M}")

Pour les structures de données, je me méfie du bricolage manuel. Une liste de tags s’affiche mieux avec " , ".join(...) qu’avec une concaténation répétée, et un dictionnaire imbriqué se lit beaucoup mieux avec json.dumps(..., indent=2, ensure_ascii=False) qu’avec une succession de print(). C’est particulièrement vrai en backend, où l’on cherche souvent à produire des logs lisibles ou des extraits de réponse faciles à inspecter.

import json

tags = ["python", "backend", "securite"]
payload = {"nom": "Aline", "roles": ["admin", "editor"]}

print(", ".join(tags))
print(json.dumps(payload, ensure_ascii=False, indent=2))

Quand le formatage est lié au type de donnée, il faut penser en termes de rendu métier, pas seulement en termes de chaîne. C’est là que les erreurs les plus fréquentes apparaissent, et elles sont rarement purement syntaxiques.

Les erreurs qui cassent la clarté ou la sécurité

Le piège le plus courant, c’est de confondre formatage et protection des données. Une f-string ne sécurise rien toute seule. Si vous injectez une entrée utilisateur dans une requête SQL, dans du HTML ou dans un appel shell, vous n’êtes pas en train de formater proprement, vous êtes en train de créer une vulnérabilité. Dans ces cas-là, il faut des paramètres, un échappement adapté ou une API spécialisée.

• Construire du SQL avec une f-string : c’est simple à écrire, mais c’est précisément ce qu’il faut éviter.
• Affichage utilisateur sans locale : un montant formaté techniquement peut rester inadapté à la convention française.
• Expressions trop longues dans une f-string : dès qu’une condition ou un calcul devient complexe, la lisibilité chute.
• Masquer une erreur numérique avec un arrondi trop agressif : afficher 1.23 peut être correct pour l’interface, mais trompeur pour le diagnostic.
• Oublier la compatibilité de version : si un projet doit encore vivre sur un Python ancien, les f-strings ne sont pas disponibles partout.

Je vois aussi un autre défaut, plus subtil : formater pour le confort du développeur alors que la donnée sert à un utilisateur. Un log de debug peut accepter une sortie dense, alors qu’un écran ou un export ont besoin d’une structure plus propre, parfois plus lente à produire mais bien plus utile à la lecture.

La bonne discipline consiste donc à séparer les usages. Le formatage sert à présenter, pas à corriger un modèle de données mal pensé ni à masquer une validation absente. Une fois ce garde-fou posé, le choix de la bonne approche devient beaucoup plus simple.

Ce que je recommande dans un projet réel en 2026

Si je dois trancher vite, je pars sur une règle courte. Pour une application moderne, les f-strings sont le réflexe par défaut. Pour une chaîne réutilisable, traduisible ou construite ailleurs dans le code, format() reste très solide. Pour un code hérité, je ne réécris pas tout par principe, surtout si le style % est déjà partout et que le risque de régression est plus élevé que le gain.

• Script ponctuel : f-strings, parce qu’elles sont rapides à écrire et à lire.
• Template réutilisé ou traduit : format(), surtout avec des noms de champs explicites.
• Objet métier : un __format__ bien pensé, pour centraliser la représentation.
• Logs et débogage : f-strings avec =, tant que la chaîne reste courte.
• Code ancien : garder % si cela évite une migration coûteuse et inutile.

Sur les versions les plus récentes de Python, il existe aussi des t-strings pour des cas de traitement de templates plus avancés, mais je ne les mets pas au même niveau que les f-strings pour le formatage courant. Pour l’immense majorité des projets, le meilleur chemin reste sobre : une f-string lisible, un spécificateur clair, et une vraie attention au contexte de sortie.

Si je devais résumer la logique à retenir, je dirais ceci : choisissez d’abord la méthode la plus lisible, puis affinez le rendu seulement quand la donnée l’exige vraiment. C’est cette discipline qui produit du code Python agréable à maintenir, et des sorties réellement utiles pour les équipes comme pour les utilisateurs.