Projets
J'ai créé mon propre langage de balisage pour publier mes poèmes sur un site web.
D'un simple clic, je les injecte dans une chaîne de déploiement : de mon ordinateur vers GitHub, puis vers un bucket S3, une instance EC2, et enfin dans une base de données MySQL, à partir de laquelle un site PHP les extrait et les affiche.
Introduction
Avant d’entrer dans le concept complet, voyons comment cette page est réellement générée.
Tout le contenu textuel est stocké dans un fichier Excel, qui contient une colonne pour les balises et deux colonnes pour les langues : français et anglais.
Un script Python injecte ces données dans une base de données MySQL, et un peu de code PHP lit cette base et génère le HTML approprié en fonction des balises.
Aucun HTML n’est écrit manuellement — ce qui rend le contenu facile à maintenir, multilingue par conception, et entièrement dynamique.
Ce mécanisme représente l’architecture de base de l’ensemble du site.
Et le meilleur dans tout ça ? Je peux tout envoyer de mon disque dur au serveur en ligne en un seul clic.
N’hésitez pas à découvrir la suite ci-dessous.
Problématique
J’ai une collection de poèmes sur mon disque dur, et je souhaite les publier sous plusieurs formats différents :
La solution facile : Word
La solution la plus simple serait d’utiliser un fichier Microsoft Word.
Je peux l’exporter en PDF, en HTML, et probablement même en LaTeX. Avec une bonne utilisation des titres et du formatage, cela pourrait donner un résultat cohérent et esthétiquement agréable.
Ce ne serait pas un mauvais choix — je suis même assez sûr que c’est ce que font 95 % des auteurs de poésie. Eh bien, il se trouve que je fais partie des 5 % restants, car Word n’est tout simplement pas pratique pour moi.
Problème n°1 : Fichiers texte brut
J’écris en texte brut, avec l’ancienne version du Bloc-notes Windows.
Quand l’inspiration me vient, j’ai besoin que mon outil d’écriture apparaisse en une seconde, en un seul clic — pas plus.
Une fois le poème écrit, je dépose simplement le fichier texte dans le bon dossier.
Il peut y rester, intact, pendant des années avant d’être relu un jour.
Problème n°2 : Trop de copies
Dans un flux de travail classique, je me retrouverais avec plusieurs versions : le fichier texte brut, la version HTML sur le site, des fichiers exportés, etc.
Si je fais une correction — même une virgule — je dois la répercuter partout.
Et si j’oublie ne serait-ce qu’une fois, tout devient incohérent. Je perds la trace de la version “la plus juste”.
Un vrai cauchemar.
Problème n°3 : Poèmes complexes
La plupart de mes poèmes sont assez simples. Mais certains incluent des sauts de ligne variés, des retraits, des citations…
J’écris aussi des chansons, donc j’ai besoin de structures comme couplet, refrain, pont, etc.
Utiliser un outil comme Markdown pour ça serait bien trop limité — et inutilement compliqué.
Problème n°4 : Aucune fluidité
Écrire des poèmes, c’est agréable. Coder de petites applications aussi.
Mais envoyer les fichiers en FTP, ajouter manuellement les balises <code><p></p></code> à chaque ligne, et propager chaque correction partout…
C’est agaçant et chronophage.
Problème n°5 : Vilain petit Word
J’ai une certaine approche minimaliste. J’aime le code propre — sans lignes inutiles. Du CSS propre — sans classes superflues.
Si vous avez déjà exporté un document depuis Word, vous savez que « propre » est sûrement le dernier mot qui vous viendrait à l’esprit.
Bien sûr, je pourrais écrire un script pour nettoyer tout ça (en fait, je l’ai fait pour mes scénarios — mais c’est une autre histoire).
Mais si l’objectif est un flux de travail propre, Word devrait probablement rester à l’écart.
La vraie solution
Après avoir pris tout cela en compte, j’ai trouvé une solution plus adaptée : créer mon propre langage de balisage et construire une pipeline allant de mon disque dur local jusqu’à un serveur AWS.
Donc oui — si je devais résumer ce projet de façon un peu plus poétique ou façon “portfolio technique”, cela donnerait quelque chose comme :
J’ai créé mon propre langage de balisage pour publier mes poèmes sur un site web.
D’un simple clic, je les injecte dans une pipeline : de mon ordinateur → vers GitHub → un bucket S3 → une instance EC2 → une base MySQL, extraite par un site PHP.
Une pipeline plus courte serait techniquement possible, mais comme je dois aussi uploader tout le site — et pas seulement les poèmes — cette approche est plus logique.
Et puis, si le site web met joliment en valeur la partie poétique, GitHub est le bon endroit pour mettre en avant la partie code.
Et puisque l’on parle de poésie et de code, voyons à quoi ressemble concrètement mon langage de balisage maison.
Lyra, un langage de balisage pour la poésie
Créer un tel langage présente plusieurs défis.
Typographie multilingue
Le principal, ce sont les règles typographiques. J’écris principalement en français, mais parfois aussi en anglais — et leurs conventions de ponctuation et de typographie sont très différentes.
LaTeX gère cela plutôt bien, mais HTML, pas du tout.
Mon texte maître doit donc rester aussi neutre que possible typographiquement.
Ensuite, le script de conversion se charge de corriger les incohérences et d’appliquer le formatage correct selon la langue.
Voici un petit exemple pour illustrer le problème :
Certaines personnes demanderaient : “What is typography?” That’s a legit question—that I need to answer in French.
Vous demandez donc : « qu’est-ce que la typographie ? » Je vous répondrais bien — mais plus tard.
On voit clairement les différences : “ ” vs. « » ; espaces fines ou absentes ; tirets cadratins ou simples traits…
Tout cela doit être géré automatiquement, et avec soin.
Contraintes LaTeX
J’adore publier avec LaTeX, mais LaTeX a ses propres exigences.
Par exemple, il n’aime pas le caractère “—” et préfère que l’on écrive “<code>---</code>” à la place.
Après des années d’utilisation de LaTeX, taper “<code>--</code>” et “<code>---</code>” est devenu un réflexe.
De plus, comme mentionné précédemment, LaTeX attend des espaces typographiques à l’anglaise par défaut, puis applique les règles correctes selon la langue définie.
Je n’aimerais pas contrarier Monsieur LaTeX — alors je m’y plie volontiers.
Chansons & poésie
Comme vous le savez déjà, j’écris de la poésie — très bien.
Mais j’écris aussi des chansons, ce qui signifie que j’ai besoin d’un balisage pour les couplets, refrains, ponts, et autres.
Ce n’est pas un énorme défi, mais c’est quelque chose que mon langage de balisage doit pouvoir gérer.
Le langage
En prenant en compte toutes ces contraintes, j’ai conçu un langage de balisage personnalisé que j’ai appelé Lyra — probablement parce que je suis un peu trop obsédé par la culture de la Grèce antique.
Vous pouvez voir l’implémentation complète dans le panneau de code, mais voici les principales transformations qu’il applique :
text = text.replace('\u202f',' ').replace('\u00a0',' ').replace('\t',' ')
text = re.sub(r'\s{2,}',' ', text)
Cette première étape supprime tous les caractères invisibles comme :
Tous sont remplacés par une espace standard.
Ensuite, <code>r'\s{2,}'</code> réduit les doubles espaces ou plus à un seul, garantissant que le texte traité est propre et cohérent.
text = text.replace("<<","« ").replace(">>"," »")
text = text.replace("+-+","—").replace("=+=","[…]")
Même principe ici : je remplace des balises spécifiques par les caractères typographiques attendus.
if typographie=="fr":
text = re.sub(r'(?<! )([!?;:])', '\u202f\\1', text)
else:
text = re.sub(r'\s+([!?;:])', r'\1', text)
Et c’est là que ça devient intéressant : les règles typographiques changent selon la langue.
Si la langue est le français, on ajoute une espace fine avant certaines ponctuations.
Si c’est l’anglais, on suit les règles d’espacement classiques de l’anglais.
text = text.strip()
text = re.sub(r'<!--.*?-->', '', text)
text = re.sub(r'%.*$', '', text)
return text
Nettoyage final : <code>strip()</code> supprime les espaces en début et fin de texte.
Les lignes <code>re.sub</code> suppriment les commentaires HTML et les lignes commençant par <code>%</code>, que j’utilise comme annotations internes.
Ponctuation
’, ‘, ‛ → '
----, ---, --, – → —
… → …
<< → «
>> → »
+-+ → —
=+= → […]
Commentaires
<!-- xxx --> → supprimé
% → supprimé
Style de police
* xxx * → italique
*µ xxx µ* → gras
*µµ xxx µµ* → italique gras
££ → acrostiche
Titres
# → Titre
## → Auteur
### → Titre du recueil
#### → Année
##### → Sous-titre
>$ → Numéro de partie
Hors-vers
<=+ xxx +=> → Texte hors vers
<+ xxx +> → Citation
<++ xxx ++> → Auteur de la citation
Structure de chanson
²cpl1 → fr : [Couplet 1] en : [Verse 1]
²rfn1 → fr : [Refrain 1] en : [Chorus 1]
²pnt → fr : [Pont] en : [Bridge]
²rnv → fr : [Renvoi]en : [Tag]
²itl → [Interlude]
²int → [Intro]
²out → [Outro]
²brp → (bis repetitas)
Alignements
<= xxx => → Centré
<== xxx ==> → Aligné à droite
Strophes
>= → Saut de ligne simple
>== → Saut de ligne moyen
>=== → Saut de ligne large
Indentations
>+ → Indentation simple
>++ → Indentation moyenne
>+++ → Indentation large
>++++ → Décalage à droite
Étape suivante
Une fois le langage de balisage défini et le script Python de conversion prêt, il était temps de passer à l’étape suivante :
construire la pipeline pour publier les poèmes en ligne.
Construction du projet
Depuis mon PC → GitHub → S3 → Lambda → EC2 → scripts Python → MySQL.
J’ai conçu un langage de balisage maison (Lyra) pour gérer la typographie multilingue, et structuré le site autour de vrais services AWS : VPC, EC2, S3, Route 53, IAM, etc.
Le développement local se fait sous Windows avec des scripts batch et shell déclenchant GitHub Actions. Le tout est automatisé et dynamique.
La pipeline
Le concept est simple : publier de nouveaux poèmes en ligne en un seul clic.
À l’époque, on faisait ça avec un bon vieux serveur FTP — on se connectait, on déposait les fichiers dans le client, et le site était mis à jour.
Ce n’était pas exactement un “clic”, mais ça s’en approchait.
Malheureusement, cette époque est en grande partie révolue (bon, pas complètement — je vois encore des multinationales fonctionner comme ça quotidiennement, mais passons).
Aujourd’hui, nous vivons à l’ère du Cloud, et comme je développe mes compétences sur AWS, voici comment fonctionne ma pipeline :
Et voilà — mon site est mis à jour, et toute ma poésie est en ligne.
En parallèle, je traite aussi un fichier Excel contenant tout le contenu en français et en anglais pour le site, je convertis certains documents Word en HTML, etc.
Comme vous pouvez le voir, c’est une pipeline amusante. Restez dans les parages pour plus de détails techniques.
Création des comptes
Créer tous les comptes a en réalité été la dernière étape du projet — mais il est plus logique de la présenter au début de cette histoire.
J’ai donc souscrit à un compte AWS, créé un VPC, lancé une instance EC2, ouvert un bucket S3, et enregistré mon nom de domaine fdelancelot.com via Route 53.
J’ai également configuré les comptes IAM et les rôles de sécurité — mais nous y reviendrons plus tard.
J’ai aussi créé un dépôt sur GitHub, ce qui m’a permis de préparer l’ensemble de la pipeline, du développement local au déploiement dans le cloud.
Environnement de développement local (Windows)
Je joue et j’enregistre de la musique. Pendant de nombreuses années, la plupart des outils de production musicale n’étaient pas disponibles sur Linux — c’est l’une des raisons pour lesquelles je travaille encore sur Windows aujourd’hui.
Sur mon ordinateur, j’ai un dossier Writing qui contient toutes mes créations, organisées en sous-dossiers :
Quand un projet est terminé, je l’enregistre au format texte brut avec une extension <code>.ryu</code>.
À partir de là, je peux l’exporter en LaTeX, PDF ou HTML.
Pour des œuvres plus complexes, comme les romans ou les scénarios, j’utilise des modèles Word spécifiques, que j’ai perfectionnés avec le temps et que j’utilise au quotidien.
Ainsi, la toute première étape de ma pipeline consiste simplement à récupérer les fichiers que je souhaite publier en ligne.
Fichier batch & fichier sh
Pour la poésie, j’utilise un fichier Batch qui copie tous les fichiers <code>.ryu</code> — en respectant l’arborescence — dans mon dépôt local.
Ce même script copie également les fichiers <code>.ryu</code> du dossier Short Novels et les fichiers <code>.docx</code> du dossier Scripts dans leurs emplacements respectifs du dépôt.
Enfin, le fichier batch lance un script Shell dans Git Bash afin de synchroniser le dépôt avec GitHub.
Ce push déclenchera ensuite une GitHub Action — mais nous verrons cela dans la section suivante.
GitHub
Comme ce site web fait aussi office de portfolio, j’utilise évidemment GitHub comme partie intégrante de la pipeline.
Cela me permet de montrer mon code et d’assurer le versioning.
Quand je pousse le dépôt avec mon script shell, cela déclenche une GitHub Action qui téléverse automatiquement une archive ZIP du site web vers mon bucket S3.
Ça, c’était la partie facile.
Maintenant vient la partie amusante : configurer toute l’architecture AWS.
Configuration AWS
Je pourrais facilement écrire des milliers de lignes sur la manière dont j’ai configuré mon architecture AWS,
mais pour rester lisible, voici une liste résumée de ce qui a été déployé.
VPC
Une instance EC2 est déployée dans ce VPC et accessible en SSH via une clé <code>.pem</code>.
Instance EC2
Amazon S3
Amazon Route 53
Nom de domaine fdelancelot.com acheté directement via Route 53.
Lambda
Une fonction Lambda a été créée pour transférer le fichier <code>.zip</code> du bucket S3 vers l’instance EC2.
Elle est déclenchée automatiquement à chaque téléversement du fichier (manuellement ou via GitHub Action).
Autres configurations AWS
IAM
Sécurité
Écosystème Python & automatisation
Récapitulatif
Reprenons la séquence complète du déploiement depuis le début :
deploy.py
Le script deploy.py orchestre tout le processus de déploiement :
poemstohtml.py
Ce script convertit les poèmes au format <code>.ryu</code> en HTML.
Vous l’avez déjà vu — il transforme le contenu écrit en langage de balisage Lyra en HTML et envoie chaque poème dans la table <code>poems</code> de la base de données MySQL.
Chaque poème est stocké sur une seule ligne.
La table de base de données utilise de jolis noms de colonnes en français :
uid → Un identifiant unique
id_logique→ Un identifiant construit à partir des initiales de la compilation et du poème
titre → Le titre du poème
recueil → Le titre de la compilation
type → Le type (ex. poème, chanson, etc.)
fichier → Le nom du fichier original
contenu → Le contenu HTML complet
date_import → Je vous laisse traduire celui-là ;)
Le <code>id_logique</code> suffit pour récupérer un poème spécifique, appeler une compilation entière, ou respecter l’ordre voulu en fonction des noms de fichiers.
screenplayconvert.py
Ce script parcourt tous les fichiers <code>.docx</code> du dossier Scripts et les convertit en fichiers <code>.php</code> prêts à être inclus directement sur le site web.
Il existe des bibliothèques Python capables de faire cela automatiquement — mais le coder entièrement à la main était plus amusant.
Pas forcément le choix le plus malin, certes, mais un bon exercice d’artisanat.
translationxlsx.py
C’est le cœur du site web.
Je maintiens un fichier Excel qui contient :
Le script envoie la clé combinée et les deux chaînes de texte dans une table MySQL à 3 colonnes.
Sur le site, une fonction PHP appelle la bonne chaîne de texte en fonction de la page courante et de la langue sélectionnée, en utilisant la clé comme argument.
Structure des fichiers
Sections principales identifiées
Architecture du site web
Il s’appuie sur PHP et MySQL pour afficher dynamiquement le contenu multilingue depuis une table de traduction.
Chaque page est chargée via une structure centrée sur index.php, avec un traitement particulier pour les nouvelles .ryu et un affichage dynamique de la poésie.
Tout repose sur un système de clefs structuré : page.section.subsection.numero.
Ce site a un double objectif :
mettre en valeur à la fois mon travail artistique (musique, poésie, scénarios) et mes compétences techniques en technologies AWS.
Voici comment le site est structuré :
L’ensemble du site est multilingue (anglais/français).
Une simple fonction PHP lit la variable <code>$_GET['l']</code> pour déterminer la langue de la page, puis récupère le contenu correspondant depuis la base MySQL.
function t(string $key): void {
global $pdo, $l;
$stmt = $pdo->prepare("SELECT content FROM translations WHERE lang = :lang AND `key` = :key LIMIT 1");
$stmt->execute([':lang' => $l, ':key' => $key]);
$text = $stmt->fetchColumn() ?: "[$key]";
$text = allowtags($text);
echo $text;
}
Architecture PHP
Le site repose sur un fichier central : <code>index.php</code>.
Ce fichier charge les composants suivants :
Entre la navigation et le pied de page, l’une des pages de contenu principales est incluse, selon la route choisie :
Il existe aussi 6 fichiers <code>.ryu</code> de nouvelles courtes, qui sont convertis dynamiquement en PHP et inclus dans une zone repliable déclenchée par un bouton — nous y reviendrons plus tard.
Deux fichiers PHP spéciaux — <code>mariup.php</code> et <code>souven.php</code> — affichent respectivement une pièce de théâtre et un scénario, tout en conservant la mise en page et l’architecture générale du site.
Détails de chaque page
La plupart des pages sont générées en suivant la même logique :
Une fonction PHP boucle sur une clé de traduction au format <code>page.section.soussection.numéro</code>, et continue à incrémenter le numéro tant qu’il reste du texte à afficher.
La page Poésie utilise le même principe, mais à une échelle beaucoup plus grande — elle affiche dynamiquement l’intégralité de la table <code>poems</code>.
La section Nouvelles est un peu plus avancée :
Elle scanne dynamiquement le dossier <code>nouvelles</code> pour y détecter tous les fichiers <code>.ryu</code>, les convertit en HTML, et les associe à leur résumé correspondant issu de la table de traduction.
Chaque nouvelle est ensuite intégrée dans un composant repliable, déclenché par un bouton.
Cette méthode évite de surcharger la page en contenu, et garantit une mise en page lisible et épurée.
Conclusion
J’ai tout construit moi-même en PHP, Python et MySQL, avec un langage de balisage personnalisé et une pipeline automatisée.
L’architecture repose sur AWS (EC2, S3, Lambda, Route 53, etc.), et tout le contenu est modulaire, multilingue et à faible coût.
J’ai atteint quasiment tous mes objectifs, tout en identifiant des axes d’amélioration : SEO, composants Vue.js, et validateur Lyra.
Objectifs principaux
En concevant ce site web, j’avais plusieurs objectifs en tête :
Axes d’amélioration
J’aime travailler avec PHP, mais il est peut-être temps d’envisager une transition vers un framework Python complet comme Flask.
Comme je préfère les sites web minimalistes et légers, adopter Tailwind CSS permettrait d’éliminer les 98 % de classes inutilisées de Bootstrap.
À l’inverse, je pourrais aussi explorer davantage les composants intégrés de Bootstrap — comme les modales ou les carrousels.
Outils & syntaxes utilisés
Environnement de développement local
Langages de programmation
Librairies & Frameworks
Services AWS
Technologies serveur
Structure & formats personnalisés
Automatisation & DevOps
Analyse finale
Certains points restent à améliorer (richesse visuelle, SEO, usage avancé de Python/MySQL), mais dans l’ensemble, ce projet prouve mes compétences à la fois techniques et artistiques.
Ai-je atteint tous mes objectifs ?
? Créer un site web élégant et responsive — OUI
Ce portfolio a pour but de démontrer mes compétences AWS, donc il est probable qu’il soit consulté sur ordinateur par des recruteurs.
Cela dit, nous vivons à l’ère du mobile, donc un design responsive était essentiel.
Ce n’est pas une vraie approche “mobile-first”, mais le site reste parfaitement lisible sur mobile.
Esthétiquement, je ne suis pas un designer professionnel, mais je trouve l’interface Noir & Or plutôt élégante — elle correspond bien à mon univers artistique.
Je suis particulièrement fier de mes boutons personnalisés : transparents au repos, remplis au clic.
? Interface i18n (multilingue) — OUI
L’interface multilingue est très facile à maintenir — tout est centralisé dans un seul fichier Excel.
Ajouter une langue serait simple (si on oublie le temps de traduction en soi).
? Chargement rapide des pages — OUI
AWS semble bien tenir la route, et j’ai fait de mon mieux pour garder le site léger : peu d’images, bibliothèques et polices en CDN.
? Pipeline de déploiement en un clic — OUI
C’est le cœur du projet — et ça fonctionne parfaitement.
Un simple clic sur un fichier batch déclenche toute la chaîne automatisée.
? Publication de poésie via mon langage de balisage, sans modification — OUI
J’ai ajusté quelques détails pour plus de clarté, et modifié rapidement le script de conversion Python→LaTeX — moins de 30 minutes.
Donc oui, c’est une réussite totale.
? Présentation de mon travail artistique (musique, écrits, etc.) — Partiellement OUI
J’imaginais quelque chose de plus visuel : photos de groupes, lecteur audio, vidéos intégrées, etc.
Techniquement faisable, mais cela risquait d’alourdir la navigation.
Pour l’instant, des liens clairs vers les pages SoundCloud et YouTube suffisent.
C’est plus sobre que prévu, mais aussi plus lisible — ce qui est une forme de réussite.
? Code propre et minimaliste — OUI
Le projet contient beaucoup de fichiers et de fonctions — ce qui est normal vu sa complexité.
J’ai fait un vrai effort pour éviter les redondances, écrire une logique claire, et commenter partout où c’était nécessaire.
? Hébergé sur AWS avec un vrai déploiement technique — OUI
Le déploiement sur AWS a été bien plus complexe que prévu.
Étudier pour la certification Cloud Practitioner est une chose — déployer concrètement en est une autre.
De l’ouverture d’une session SSH à l’attribution des rôles Lambda, ça a été un apprentissage profond et enrichissant.
Clairement, une certification seule ne suffit pas pour être opérationnel. Ce projet me l’a prouvé.
? Utiliser ce site comme portfolio en recherche d’emploi — OUI (je l’espère)
Je dis “oui”, mais en réalité : je l’espère.
Je crois que ce projet reflète ce que je suis capable de faire — techniquement et artistiquement.
? Apprendre de nouvelles compétences — OUI
J’ai énormément appris — surtout sur AWS, mais pas uniquement :
connexions SSH, installation LAMP, environnement Linux, configuration Apache, VPC personnalisé…
Ma préparation à la certification CCNA m’a beaucoup aidé, surtout sur la partie réseau.
J’ai aussi affiné mes compétences en code, et même découvert quelques astuces CSS inattendues.
? Utiliser Python — Partiellement OUI
J’ai utilisé Python intensivement, mais dans une zone de confort : pas encore d’algorithmes avancés ni d’API externes.
? Rester sous budget (< 5€/mois) — OUI
À part le nom de domaine, tout tourne à 0€/mois grâce au Free Tier AWS. Parfait.
? Site web dynamique — OUI
Le site est entièrement dynamique.
Presque tout repose sur PHP : les poèmes sont générés à la volée, et le contenu est chargé via des fonctions de traduction ou des requêtes SQL.
? Structure modulaire, facile à maintenir — OUI
Stocker tout le texte dans un fichier Excel rend la mise à jour ultra simple :
il suffit d’ajouter une ligne avec la bonne clé, et la fonction PHP l’affiche.
Pour la poésie, c’est encore plus simple : ajouter ou renommer un fichier <code>.ryu</code> localement suffit — le site le reconnaît automatiquement.
? URLs propres (sans <code>$_GET[]</code> dégueu) — OUI
Au départ, j’avais tout basé sur un seul <code>index.php</code> : élégant, mais catastrophique pour le SEO.
J’ai donc retravaillé les URLs pour qu’elles soient propres et indexables — et j’en suis très satisfait.
? Utiliser MySQL — Partiellement OUI
J’ai utilisé MySQL, mais de manière assez basique.
La seule vraie nouveauté, c’était le déploiement de MariaDB sur mon serveur EC2.
Cela reste une bonne base.
? Zéro framework, projet 100% maison — OUI (en grande partie)
Je n’ai utilisé aucun CMS lourd comme WordPress — et c’était volontaire.
J’utilise tout de même quelques bibliothèques JS (PureCounter, Waypoints, etc.), et bien sûr Bootstrap.
Écrire mes propres widgets JS aurait été un bon exercice — je le ferai peut-être plus tard.
Mais Bootstrap ? C’est un bon compromis.
Assez léger, et comme ce n’est que du CSS et du JS, je garde la main sur tout le reste.
Utiliser un framework CSS minimal m’a permis de me concentrer sur la logique — et c’était le bon choix.
Et ce sera le mot de la fin : utiliser juste ce qu’il faut de framework pour rester efficace, sans jamais perdre le contrôle.
Merci d’avoir lu ce très long texte.