Aither (Français)

Bien démarrer avec Astro-Theme-Aither

Sat, 14 Mar 2026 08:00:00 GMT

Ce guide vous accompagne depuis une installation vierge jusqu’à un blog multilingue déployé. Lisez-le du début à la fin ou allez directement à la section utile. ## Prérequis - [Node.js](https://nodejs.org/) 22 LTS ou plus récent - [pnpm](https://pnpm.io/) 10 ou plus récent - Un compte GitHub - Un compte [Cloudflare](https://cloudflare.com/) pour le déploiement ## Installation ```bash git clone https://github.com/YOUR_USERNAME/YOUR_REPO.git cd YOUR_REPO corepack enable pnpm install pnpm validate pnpm dev ``` Ouvrez ensuite `http://localhost:4321`. ## Structure du projet ```text src/ ├── components/ # Composants Astro et React ├── config/site.ts # Nom du site, navigation, footer, réseaux ├── content/posts/ # Articles organisés par locale ├── i18n/ # Traductions de l’interface ├── layouts/ # Layouts ├── lib/ # Utilitaires ├── pages/ # Pages et routes └── styles/global.css # Tokens Tailwind v4 ``` ## Configuration ### Site Config `src/config/site.ts` est la source unique de vérité pour le site : ```typescript export const siteConfig = { name: 'Le nom de votre blog', title: 'Votre signature', description: 'Votre description SEO', author: { name: 'Votre nom', avatar: '', }, }; ``` ### Variables d’environnement ```bash cp .env.example .env ``` Les variables vides désactivent simplement l’intégration correspondante. ### URL du site Définissez l’URL finale dans `astro.config.mjs` : ```javascript import { defineConfig } from 'astro/config'; import aither from '@aither/astro'; export default defineConfig({ site: 'https://your-domain.pages.dev', integrations: [aither()], }); ``` ## Rédiger des articles Créez un fichier `.mdx` dans `src/content/posts/en/` : ```markdown --- title: Mon premier article date: "2026-03-14T16:00:00+08:00" category: General description: Résumé court pour le SEO et les aperçus sociaux. tags: [Topic, Another] pinned: false --- Votre contenu commence ici. ``` ### Référence du frontmatter | Champ | Type | Obligatoire | Description | |------|------|-------------|-------------| | `title` | string | Oui | Titre de l’article | | `date` | date | Oui | Date et heure de publication (ex. `2026-03-14T16:00:00+08:00`) | | `category` | string | Non | Catégorie | | `description` | string | Non | Description SEO | | `tags` | string[] | Non | Liste d’étiquettes | | `pinned` | boolean | Non | Épingler en haut | | `image` | string | Non | Image de couverture | ### Composants MDX Vous pouvez importer des composants interactifs dans vos contenus : ```mdx import MyChart from '@/components/MyChart' ``` ## Internationalisation Le thème prend en charge 11 langues. Pour traduire un article, créez le même nom de fichier dans un autre dossier de locale : ```text src/content/posts/en/my-post.mdx src/content/posts/fr/my-post.mdx src/content/posts/zh-hans/my-post.mdx ``` Les textes d’interface se trouvent dans `src/i18n/messages/`. ## Sections de contenu personnalisées Vous pouvez ajouter des collections comme des traductions, des notes ou des tutoriels via `src/content.config.ts` et `src/config/site.ts`. Les pages de liste et de détail seront générées automatiquement. ## Theming Le système repose sur deux couches : - mode de couleur : `light`, `dark`, `system` - style visuel : `default` ou un style intégré comme `evolution` ```typescript ui: { defaultMode: 'system', defaultStyle: 'default', showMoreThemesMenu: true, }, ``` Les couleurs proviennent de `src/styles/global.css`. La police par défaut est une pile sans-serif système, avec une police monospace pour le code. ## SEO et AI Chaque page expose déjà les sorties utiles suivantes : - `/sitemap-index.xml` - `/rss.xml` - `/robots.txt` - `/llms.txt` - `/llms-full.txt` - `/posts/slug.md` - JSON-LD et Open Graph ## Déploiement ### Cloudflare Pages Bonne pratique : créez d’abord le projet Pages. Le flux utilise par défaut le nom du dépôt, ou `CLOUDFLARE_PAGES_PROJECT_NAME` si vous devez le remplacer. Configurez ces secrets GitHub : - `CLOUDFLARE_API_TOKEN` - `CLOUDFLARE_ACCOUNT_ID` Ensuite, exécutez `pnpm validate` puis poussez sur `main`. ## Commandes utiles | Commande | Description | |---------|-------------| | `pnpm dev` | Lance le serveur local | | `pnpm validate` | Lance la suite complète de validation avant push | | `pnpm build` | Génère le build de production | | `pnpm preview` | Prévisualise le build localement | ## Schéma de version Les tags de release publics suivent un nommage CalVer, par exemple `v2026.04.08`.

Bonnes pratiques pour les agents IA sur de vrais projets (Exemple)

Sat, 10 Jan 2026 08:00:00 GMT

Les agents IA deviennent vraiment utiles quand ils cessent de paraître magiques et commencent à se comporter comme un outil de travail fiable. Les équipes qui obtiennent les meilleurs résultats ne demandent pas à un agent de "tout gérer". Elles définissent la tâche, fournissent le bon contexte et s'assurent que le résultat reste facile à vérifier. Cela paraît simple, mais cela change tout. Un agent bien préparé peut avancer vite et produire un travail étonnamment solide. Un agent mal cadré gaspille du contexte, prend des détours inutiles et renvoie quelque chose qui semble sûr de lui, mais qui ne traite pas vraiment le vrai besoin. ## Commencer par une tâche étroite Les meilleures tâches pour un agent sont concrètes et limitées. Au lieu de dire "améliore cette application", dites "corrige le chevauchement de la navigation mobile sur la page du blog" ou "ajoute un test rapide pour le flux RSS". Une tâche bien délimitée donne à l'agent une cible stable et réduit le risque de modifications hors sujet. Cela simplifie aussi la revue. Quand la tâche est petite, il est plus facile de voir ce qui a changé, ce qu'il faut tester et si le résultat est réellement correct. ## Rendre le contexte explicite Les agents travaillent mieux quand le contexte important est écrit noir sur blanc plutôt que laissé à l'implicite. Une bonne consigne initiale contient généralement : - l'objectif exact - les fichiers ou dossiers concernés - les contraintes et ce qui ne doit pas changer - le résultat attendu ou la définition de terminé - la commande de validation à exécuter à la fin Les humains savent déduire beaucoup de choses à partir d'instructions incomplètes. Les agents sont plus littéraux. Si un détail compte, il faut l'écrire. ## Mieux vaut des outils que des suppositions Un agent devrait inspecter le système actuel avant de proposer des changements. Cela veut dire lire les fichiers pertinents, vérifier le setup de build et comprendre les conventions existantes, plutôt que de s'appuyer sur une connaissance trop générale. La même logique vaut pour les systèmes externes. Si une réponse dépend de la documentation à jour, d'une configuration de déploiement ou d'un comportement réel, l'agent doit utiliser des outils pour vérifier l'état réel au lieu de deviner de mémoire. C'est aussi pour cela que les interfaces lisibles par machine comptent autant. Une arborescence claire, des scripts de validation, des schémas typés et une configuration explicite rendent les agents plus fiables, parce que l'environnement s'explique lui-même. ## Garder une sortie vérifiable Un bon flux de travail avec un agent ne se termine pas par "voici la réponse". Il se termine par des preuves. Demandez à l'agent d'indiquer ce qu'il a modifié, ce qu'il a testé et ce qu'il n'a pas pu vérifier. Préférez des livrables rapides à contrôler : - un petit diff - une commande de validation qui passe - une capture ou un aperçu reproductible - une note courte sur les risques ou hypothèses La vérification transforme un résultat plausible en résultat fiable. ## Concevoir pour récupérer facilement Même de bons agents prennent parfois une mauvaise direction. La bonne réponse n'est pas d'éviter les agents, mais de rendre la récupération peu coûteuse. Utilisez de petites tâches, des scripts stables et des points de contrôle. Gardez des opérations idempotentes quand c'est possible. Évitez les flux de travail où une seule erreur crée un grand désordre difficile à corriger. Si une tâche peut être découpée en lecture, planification, implémentation et vérification, faites-le. Les agents donnent le meilleur d'eux-mêmes dans des systèmes faciles à inspecter, faciles à tester et faciles à faire évoluer. ## La revue humaine reste essentielle Les agents sont excellents pour la vitesse, la couverture et la répétition. Les humains restent responsables du jugement. Les arbitrages produit, les limites de sécurité, le ton, la marque et la maintenabilité à long terme doivent toujours être revus par une personne qui comprend le contexte global. L'objectif n'est pas de sortir les humains de la boucle. L'objectif est qu'ils passent moins de temps sur le travail mécanique et davantage sur les décisions qui demandent réellement du discernement et de la responsabilité. ## Un modèle mental pratique Considérez un agent IA comme un opérateur compétent, rapide, infatigable et littéral. Donnez-lui une mission claire. Donnez-lui les bons outils. Demandez-lui de montrer son travail. Puis examinez le résultat avec la même rigueur que pour n'importe quel changement important. C'est là que se trouve le vrai levier.

Agents IA et utilisation d'outils (Exemple)

Fri, 09 Jan 2026 08:00:00 GMT

Un agent IA est un modèle de langage capable d'agir — pas seulement de générer du texte. Il peut chercher sur le web, exécuter du code, appeler des API, lire des fichiers et décider quoi faire ensuite. Ce passage de la génération passive de texte à la résolution active de problèmes représente l'une des avancées les plus significatives de l'IA appliquée. ## Du chat à l'action Un chatbot répond aux questions. Un agent résout des problèmes. La différence est l'autonomie : les agents décident quels outils utiliser, dans quel ordre, et comment gérer les erreurs. Considérez la différence en pratique. Vous demandez à un chatbot : « Quel temps fait-il à Tokyo ? » Il pourrait répondre en se basant sur ses données d'entraînement — qui datent de mois ou d'années et sont presque certainement incorrectes. Vous posez la même question à un agent, et il appelle une API météo, récupère les données actuelles et renvoie une réponse précise et à jour. Le chatbot génère du texte plausible. L'agent interagit avec le monde. ### Le spectre de l'autonomie Tous les agents ne sont pas également autonomes. Il existe un spectre : 1. **Chat assisté par outils** — le modèle peut appeler des outils, mais uniquement en réponse directe aux requêtes de l'utilisateur. Un appel d'outil par tour. 2. **Agents multi-étapes** — le modèle peut enchaîner plusieurs appels d'outils pour accomplir une tâche, décidant lui-même de la séquence. 3. **Agents entièrement autonomes** — le modèle opère indépendamment sur des périodes prolongées, prenant des décisions, gérant les erreurs et poursuivant des objectifs avec une supervision humaine minimale. La plupart des systèmes en production se situent aux niveaux 1-2. Les agents entièrement autonomes sont un domaine de recherche actif avec des défis de sécurité importants encore à résoudre. ## Utilisation d'outils L'utilisation d'outils permet à un modèle IA d'appeler des fonctions externes. Le modèle décide quand un outil est nécessaire, génère les bons paramètres et intègre le résultat dans sa réponse. Cela transforme un générateur de texte en un assistant capable. ### Comment fonctionne l'utilisation d'outils La mécanique est simple : 1. **Définition de l'outil** — vous décrivez les outils disponibles au modèle, y compris leurs noms, paramètres et ce qu'ils font. Ceci est généralement fourni sous forme de JSON structuré dans le prompt système ou via un champ API dédié. 2. **Décision** — lors du traitement d'une requête utilisateur, le modèle décide si un outil serait utile. Si oui, il génère un appel d'outil avec les paramètres appropriés. 3. **Exécution** — votre application exécute l'appel d'outil (le modèle ne l'exécute pas directement) et renvoie le résultat. 4. **Intégration** — le modèle intègre le résultat de l'outil dans sa réponse à l'utilisateur. ### Exemple de définition d'outil ```json { "name": "search_documentation", "description": "Search the product documentation for relevant articles", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "The search query" }, "max_results": { "type": "integer", "description": "Maximum number of results to return", "default": 5 } }, "required": ["query"] } } ``` Le modèle voit cette définition et sait qu'il peut rechercher dans la documentation. Quand un utilisateur pose une question sur le produit, le modèle génère un appel comme `search_documentation(query="how to reset password")`, votre système exécute la recherche, et le modèle utilise les résultats pour composer une réponse précise. ### Catégories courantes d'outils Les systèmes d'agents en production offrent généralement des outils dans plusieurs catégories : - **Récupération d'informations** — recherche web, requêtes base de données, lecture de fichiers, appels API - **Exécution de code** — exécution de Python, JavaScript ou commandes shell dans un environnement sandboxé - **Communication** — envoi d'emails, publication de messages, création de tickets - **Manipulation de fichiers** — création, édition et organisation de fichiers - **Opérations système** — déploiement de code, gestion d'infrastructure, exécution de pipelines CI Les outils que vous fournissez définissent les limites de ce que l'agent peut faire. Un ensemble d'outils bien conçu donne à l'agent suffisamment de capacités pour être utile sans assez de pouvoir pour être dangereux. ## Boucles agentiques Le pattern le plus puissant est la boucle agentique : le modèle planifie une étape, l'exécute, observe le résultat et décide de l'étape suivante. Cette boucle continue jusqu'à ce que la tâche soit terminée ou que le modèle détermine qu'il ne peut pas poursuivre. ### La boucle en pratique Considérez un agent chargé de déboguer un test échouant : 1. **Planifier** — « Je devrais d'abord lire le fichier de test pour comprendre ce qu'il teste » 2. **Exécuter** — appelle `read_file("tests/auth.test.ts")` 3. **Observer** — voit que le test attend un statut 200 mais obtient un 401 4. **Planifier** — « Je devrais vérifier le middleware d'authentification pour voir ce qui renvoie 401 » 5. **Exécuter** — appelle `read_file("src/middleware/auth.ts")` 6. **Observer** — trouve un bug dans la vérification d'expiration du token 7. **Planifier** — « Je devrais corriger la comparaison d'expiration » 8. **Exécuter** — appelle `edit_file(...)` avec la correction 9. **Observer** — confirme que la modification a été effectuée 10. **Planifier** — « Je devrais exécuter le test pour vérifier la correction » 11. **Exécuter** — appelle `run_command("pnpm test tests/auth.test.ts")` 12. **Observer** — le test passe 13. **Terminé** — rapporte la correction à l'utilisateur Chaque étape implique que le modèle raisonne sur l'état actuel, décide quoi faire ensuite et s'adapte en fonction de ce qu'il découvre. C'est fondamentalement différent d'un script linéaire — l'agent gère les découvertes inattendues et change de cap quand nécessaire. ### Gestion des erreurs dans la boucle Les agents robustes doivent gérer les échecs avec élégance. Un outil peut retourner une erreur, un fichier peut ne pas exister, ou une API peut être limitée en débit. Un bon design d'agent inclut : - **Logique de réessai** — réessayer les échecs transitoires avec un backoff - **Stratégies alternatives** — si une approche échoue, en essayer une autre - **Dégradation gracieuse** — si la tâche ne peut être complètement réalisée, accomplir autant que possible et expliquer ce qui reste - **Limites de boucle** — fixer un nombre maximum d'itérations pour éviter les boucles infinies ## Concevoir des outils efficaces La qualité d'un système d'agents dépend fortement de la qualité de ses outils. Des outils mal conçus mènent à des agents confus et des résultats incorrects. ### Principes de conception d'outils - **Noms clairs** — `search_users` est meilleur que `query_db_1`. Le modèle utilise le nom pour décider quand appeler l'outil. - **Paramètres descriptifs** — incluez des descriptions pour chaque paramètre. Le modèle lit ces descriptions pour déterminer quelles valeurs passer. - **Portée ciblée** — chaque outil devrait faire une seule chose bien. Un outil `read_file` et un outil `write_file` sont meilleurs qu'un outil `file_operations` avec un paramètre de mode. - **Erreurs utiles** — retournez des messages d'erreur clairs qui aident le modèle à comprendre ce qui s'est mal passé et quoi essayer à la place. - **Idempotent quand possible** — les outils qui peuvent être réessayés en toute sécurité simplifient la gestion des erreurs. ## Risques Les agents qui peuvent agir peuvent mal agir. Le sandboxing, les étapes de confirmation et les revues humaines sont des mesures de sécurité essentielles pour tout système d'agents en production. ### Catégories de risques - **Actions destructrices** — un agent avec accès au système de fichiers pourrait supprimer des fichiers importants. Un agent avec accès à la base de données pourrait supprimer des tables. Les environnements sandbox et les limites de permissions sont essentiels. - **Exfiltration de données** — un agent qui peut à la fois lire des données sensibles et faire des requêtes réseau pourrait involontairement (ou par injection de prompt) divulguer des informations. - **Coûts incontrôlés** — un agent dans une boucle appelant des API coûteuses peut accumuler des coûts significatifs rapidement. Les limites de budget et le rate limiting sont des nécessités pratiques. - **Actions incorrectes exécutées avec assurance** — l'agent pourrait mal comprendre une requête et prendre une action irréversible. Pour les opérations à haut risque, toujours exiger une confirmation humaine. ### Patterns de sécurité Les systèmes d'agents en production devraient implémenter plusieurs patterns de sécurité : 1. **Principe du moindre privilège** — ne donnez à l'agent que les outils nécessaires à sa tâche spécifique, rien de plus 2. **Sandboxing** — exécutez le code et les opérations sur fichiers dans des environnements isolés 3. **Portes de confirmation** — exigez l'approbation humaine pour les actions destructrices ou irréversibles 4. **Journalisation d'audit** — enregistrez chaque appel d'outil et son résultat pour revue 5. **Kill switches** — fournissez des mécanismes pour arrêter immédiatement un agent en cours d'exécution 6. **Limites de budget** — fixez des plafonds stricts pour les appels API, l'utilisation de tokens et le temps de calcul L'objectif n'est pas d'empêcher les agents d'être utiles — c'est de s'assurer qu'ils sont utiles dans des limites bien définies.

✨ Pourquoi Astro-Theme-Aither

Sat, 03 Jan 2026 08:00:00 GMT

Un thème Astro AI-natif qui croit que le texte est beau en soi. Astro-Theme-Aither est conçu pour les lecteurs qui viennent pour les mots, pas pour la décoration. ## Philosophie de design La plupart des thèmes rivalisent d'attention avec des images héros, des animations, des barres latérales et des popups. Rien de tout cela n'aide à lire — cela aide à regarder, ce qui est une activité différente. Astro-Theme-Aither prend l'approche inverse : un design minimal, pas une ingénierie minimale. Quand aucun visuel tape-à-l'œil ne masque les problèmes, chaque défaut typographique, chaque délai de chargement, chaque accroc d'interaction est amplifié. Un design minimal exige une qualité d'ingénierie supérieure, pas inférieure. ## Typographie La police est l'identité visuelle. Chaque page utilise une pile de polices système sans-sérif unifiée — nette, rapide et cohérente entre les plateformes. Les paramètres typographiques suivent les Apple Human Interface Guidelines : - **Taille de police** — 17px, le point idéal pour la lecture sur écran - **Hauteur de ligne** — 1.47 - **Espacement des lettres** — -0.022em - **Échelle des titres** — 31px → 22px → 19px → 17px - **Largeur de lecture** — contrainte à 65-75 caractères par ligne ## Construit sur Astro Astro est le meilleur framework pour les sites orientés contenu aujourd'hui. Il produit du HTML statique par défaut. L'architecture îlots signifie que les composants interactifs s'hydratent indépendamment. Les îlots interactifs d'Astro-Theme-Aither sont minimaux : - **Commutateur de thème** — toggle Clair / Sombre / Système avec animation circulaire View Transitions API - **Commutateur de langue** — changement de locale fluide avec persistance localStorage - **Détection de locale** — détecte automatiquement la langue du navigateur - **Navigation mobile** — menu hamburger responsive ## Fonctionnalités - **Tailwind CSS v4** — tokens de design `@theme` - **Typographie Apple HIG** — paramètres 17px / 1.47 / -0.022em - **View Transitions API** — animation de révélation circulaire - **i18n** — support multilingue avec détection automatique - **Épinglage d'articles** — épinglez les articles importants en haut de la liste - **Content Collections** — Markdown type-safe - **Mode sombre** — Clair / Sombre / Système - **SEO** — Open Graph, URLs canoniques - **RSS + Sitemap** — auto-générés - **Google Analytics** — optionnel, dans un Web Worker Partytown - **Tests** — Vitest + Playwright, intégrés au CI - **Cloudflare Pages** — flux de déploiement avec URLs de prévisualisation ## Pour qui ? Si vous croyez que la bonne écriture parle d'elle-même : - **Blogueurs personnels** — qui veulent leur écriture au premier plan - **Rédacteurs techniques** — qui ont besoin d'un excellent rendu des blocs de code - **Auteurs multilingues** — qui ont besoin du i18n intégré - **Développeurs** — qui apprécient un code bien conçu Écrivez sur n'importe quel sujet — la typographie le rendra beau.

📝 Guide de style Markdown

Fri, 02 Jan 2026 08:00:00 GMT

Cet article présente toutes les fonctionnalités Markdown supportées par Astro-Theme-Aither. Utilisez-le comme référence pour rédiger vos propres articles. Ajoutez-le à vos favoris — il couvre l'ensemble des options de formatage disponibles. ## Titres Utilisez `##` pour les titres de section, `###` pour les sous-sections et `####` pour les sous-sous-sections. Évitez `#` dans le contenu — le titre de l'article est déjà rendu comme titre principal. ### Titre de niveau 3 Les titres de troisième niveau sont idéaux pour diviser une section en sujets distincts. Ils créent une hiérarchie visuelle sans être trop proéminents. #### Titre de niveau 4 Les titres de quatrième niveau conviennent aux sous-sections détaillées. Utilisez-les avec parcimonie — si votre plan descend au-delà de quatre niveaux, envisagez de restructurer votre contenu. ### Bonnes pratiques pour les titres Quelques lignes directrices pour une utilisation efficace des titres : - **Ne sautez pas de niveaux** — passez de `##` à `###`, jamais directement de `##` à `####`. Sauter des niveaux casse la structure du document et peut perturber les lecteurs d'écran. - **Gardez des titres descriptifs** — « Configuration » est préférable à « Trucs de réglages ». Les lecteurs parcourent les titres avant de décider s'ils lisent une section. - **Utilisez la casse de phrase** — majuscule uniquement au premier mot et aux noms propres. ## Paragraphes et sauts de ligne Le texte de paragraphe coule naturellement. Laissez une ligne vide entre les paragraphes pour les séparer. Ceci est un second paragraphe. Gardez les paragraphes centrés sur une seule idée pour la meilleure expérience de lecture. Pour le web, les paragraphes courts fonctionnent mieux que les longs blocs de texte. Un paragraphe de trois à cinq phrases est une unité de lecture confortable sur écran. Si un paragraphe dépasse six ou sept phrases, envisagez de le diviser. Les sauts de ligne simples dans un paragraphe (sans ligne vide) seront traités comme un espace, pas comme une nouvelle ligne. Si vous avez besoin d'un saut de ligne dur sans nouveau paragraphe, terminez la ligne par deux espaces ou utilisez une balise `
` — bien que ce soit rarement nécessaire en pratique. ## Mise en forme - **Texte en gras** avec `**doubles astérisques**` - *Texte en italique* avec `*astérisques simples*` - ***Gras et italique*** avec `***triples astérisques***` - ~~Barré~~ avec `~~doubles tildes~~` ### Quand utiliser chaque style Le **gras** fonctionne le mieux pour les termes clés, les avertissements importants ou les définitions — tout ce que le lecteur ne devrait pas manquer même en parcourant rapidement. Utilisez-le pour la phrase la plus importante d'un paragraphe, pas pour des phrases entières. L'*italique* sert pour l'emphase dans une phrase, les titres de livres et publications, les termes techniques à leur première utilisation et les expressions étrangères. Il fournit une emphase plus légère que le gras. Le ~~barré~~ est utile pour montrer des corrections, des informations obsolètes ou des éléments complétés dans un changelog. Il a un champ d'utilisation plus restreint mais est précieux quand vous en avez besoin. ## Liens [Lien inline](https://astro.build) avec la syntaxe `[texte](url)`. Les liens peuvent aussi référencer d'autres articles sur votre site en utilisant des chemins relatifs. Utilisez un texte de lien descriptif — « lisez le guide Markdown » est mieux que « cliquez ici ». Un bon texte de lien aide à la fois les lecteurs et les moteurs de recherche à comprendre où mène le lien. Vous pouvez aussi créer des liens qui s'intègrent dans le contexte en écrivant un texte d'ancrage descriptif qui se lit naturellement dans la phrase. Par exemple : la [documentation Astro](https://docs.astro.build) couvre chaque fonctionnalité en détail. ## Listes Liste non ordonnée : - Premier élément - Deuxième élément - Élément imbriqué - Autre élément imbriqué - Troisième élément Liste ordonnée : 1. Première étape 2. Deuxième étape 1. Sous-étape un 2. Sous-étape deux 3. Troisième étape Liste de tâches : - [x] Configurer le projet - [x] Écrire le premier article - [ ] Déployer en production ### Conseils de formatage des listes Les listes sont l'un des outils les plus efficaces en rédaction web. Elles découpent le texte dense, rendent l'information scannable et communiquent clairement des séquences ou collections d'éléments. **Utilisez les listes non ordonnées** quand les éléments n'ont pas de séquence inhérente — fonctionnalités, exigences, options ou exemples. **Utilisez les listes ordonnées** quand la séquence compte — étapes d'un processus, éléments classés ou instructions à suivre dans l'ordre. **Utilisez les listes de tâches** pour suivre la progression, les checklists de projet ou les éléments à faire. Gardez les éléments de liste parallèles en structure. Si le premier élément commence par un verbe, tous les éléments devraient commencer par un verbe. ## Citations > Le but de l'abstraction n'est pas d'être vague, mais de créer un nouveau niveau sémantique dans lequel on peut être absolument précis. > > — Edsger W. Dijkstra Citations imbriquées : > Premier niveau > > > Deuxième niveau > > > > > Troisième niveau ### Utilisation des citations Les citations servent plusieurs objectifs au-delà de citer des personnes célèbres : - **Citer des sources** — en référençant un autre article, livre ou document - **Annotations** — mettre en évidence des informations importantes ou des avertissements - **Style email** — montrer ce que quelqu'un a dit dans une conversation à laquelle vous répondez - **Citations d'accroche** — attirer l'attention sur un passage clé de votre propre article Lors de l'utilisation de citations avec attribution, placez le nom de l'auteur sur une ligne séparée précédée d'un tiret cadratin, comme montré dans l'exemple de Dijkstra ci-dessus. ## Code Code `inline` avec des backticks. Utilisez le code inline pour les noms de fonctions comme `getPublishedPosts()`, les chemins de fichiers comme `src/content/posts/`, les instructions en ligne de commande comme `pnpm dev` et toute valeur littérale apparaissant dans le texte courant. Bloc de code avec coloration syntaxique : ```typescript interface Post { title: string; date: Date; description?: string; tags?: string[]; draft?: boolean; } function getPublishedPosts(posts: Post[]): Post[] { return posts .filter((post) => !post.draft) .sort((a, b) => b.date.getTime() - a.date.getTime()); } ``` ```css @theme { --font-sans: 'system-ui', sans-serif; --font-serif: 'ui-serif', 'Georgia', serif; } ``` ### Conseils pour les blocs de code Spécifiez toujours l'identifiant de langage après les triples backticks d'ouverture. Cela active la coloration syntaxique, qui améliore considérablement la lisibilité. Les identifiants courants incluent `typescript`, `javascript`, `css`, `html`, `bash`, `json`, `python` et `markdown`. Pour les commandes shell, utilisez `bash` ou `sh` : ```bash # Installer les dépendances pnpm install # Démarrer le serveur de développement pnpm dev # Compiler pour la production pnpm build ``` Pour les fichiers de configuration JSON : ```json { "name": "my-blog", "version": "1.0.0", "scripts": { "dev": "astro dev", "build": "astro build" } } ``` Gardez les blocs de code ciblés. Montrez uniquement les lignes pertinentes plutôt que de coller un fichier entier. Si du contexte est nécessaire, ajoutez un commentaire indiquant où se trouve le code. ## Tableaux | Fonctionnalité | Statut | Notes | |---|---|---| | Mode sombre | Supporté | Clair / Sombre / Système | | Flux RSS | Intégré | `/rss.xml` | | Plan du site | Auto-généré | Via `@astrojs/sitemap` | | SEO | Intégré | Open Graph + canonique | Colonnes alignées à droite et centrées : | Gauche | Centre | Droite | |:---|:---:|---:| | Texte | Texte | Texte | | Texte plus long | Texte plus long | Texte plus long | ### Directives pour les tableaux Les tableaux fonctionnent mieux pour les données structurées avec des colonnes et lignes clairement définies. Ils sont idéaux pour les comparaisons de fonctionnalités, les options de configuration, les paramètres d'API et les données de référence. Gardez les tableaux simples. Si un tableau a plus de cinq ou six colonnes, il devient difficile à lire sur mobile. Envisagez de diviser les tableaux complexes en plusieurs plus petits, ou utilisez un format de liste à la place. L'alignement des colonnes se contrôle avec des deux-points dans la ligne de séparation : - `:---` pour l'alignement à gauche (par défaut) - `:---:` pour le centrage - `---:` pour l'alignement à droite Utilisez l'alignement à droite pour les données numériques afin que les points décimaux s'alignent visuellement. ## Ligne horizontale Utilisez `---` pour créer une ligne horizontale : --- Contenu après la ligne. Les lignes horizontales sont utiles pour séparer les sections majeures d'un article, indiquer un changement de sujet ou découper visuellement les articles très longs. Utilisez-les judicieusement — si vous avez besoin de séparateurs fréquents, les titres pourraient être un meilleur choix structurel. ## Images Les images sont supportées avec la syntaxe Markdown standard : ```markdown ![Texte alternatif](./image.jpg) ``` Ce thème est centré sur la typographie, mais les images fonctionnent quand vous en avez besoin. ### Bonnes pratiques pour les images - **Toujours inclure un texte alternatif** — il est essentiel pour l'accessibilité et apparaît aussi quand les images ne se chargent pas - **Utiliser des noms de fichiers descriptifs** — `dashboard-error-state.png` est mieux que `screenshot-2.png` - **Optimiser la taille des fichiers** — compressez les images avant de les ajouter à votre dépôt ; les images lourdes ralentissent le chargement des pages - **Considérer le flux de lecture** — placez les images près du texte qui les référence, pas à des paragraphes de distance ## Conclusion Les fonctionnalités Markdown décrites dans ce guide couvrent la grande majorité de ce dont vous aurez besoin pour écrire un blog. La clé d'un bon Markdown est d'utiliser le bon élément pour le bon usage : les titres pour la structure, la mise en forme pour l'importance, les listes pour les collections, les blocs de code pour le contenu technique et les paragraphes pour tout le reste. Écrivez clairement, formatez avec cohérence et laissez la typographie faire son travail.

👋 Bonjour le monde

Thu, 01 Jan 2026 08:00:00 GMT

Bienvenue dans Astro-Theme-Aither. Ce thème repose sur une conviction : une bonne écriture mérite une bonne typographie. Des titres sérifs, un rythme de lecture fluide et une mise en page qui s'efface. Tout ici sert un seul objectif — donner à vos mots la beauté qu'ils méritent. ## Pourquoi un autre thème de blog Le web regorge de thèmes, et il est donc légitime de se demander pourquoi en créer un nouveau. La réponse tient aux priorités. La plupart des thèmes optimisent l'impact visuel — grandes images d'en-tête, mises en page complexes, transitions animées. C'est saisissant en démo, mais gênant quand quelqu'un s'assoit pour lire un article de 2 000 mots. Astro-Theme-Aither part d'une prémisse différente. Le contenu est le produit. Le rôle du thème est de présenter ce contenu avec le soin qu'il mérite : des associations typographiques réfléchies, des espaces généreux et un rythme vertical qui rend la lecture longue confortable plutôt qu'épuisante. Cette philosophie s'étend aux choix techniques. Le thème envoie environ 0,5 Ko de JavaScript côté client — juste assez pour le commutateur de thème. Tout le reste est du HTML et CSS statiques. ## Démarrage La mise en route prend quelques minutes : 1. **Cloner le dépôt** — utilisez le bouton template GitHub ou clonez directement avec `git clone` 2. **Installer les dépendances** — exécutez `pnpm install` 3. **Configurer votre site** — éditez `src/config/site.ts` 4. **Remplacer le contenu** — remplacez les articles dans `src/content/posts/` par vos propres fichiers Markdown 5. **Développer** — lancez `pnpm dev` 6. **Déployer** — poussez sur GitHub et le flux CI intégré gère le déploiement sur Cloudflare Pages ### Structure du projet ``` src/ ├── components/ # Composants Astro réutilisables ├── config/ # Configuration du site ├── content/ # Vos articles et contenus Markdown ├── layouts/ # Mises en page (Layout.astro) ├── pages/ # Pages de routes └── styles/ # CSS global avec tokens Tailwind v4 ``` ### Écrire votre premier article Créez un nouveau fichier `.md` dans `src/content/posts/` avec le frontmatter suivant : ```markdown --- title: Titre de l'article date: "2026-01-15T16:00:00+08:00" category: General description: Un bref résumé pour le SEO et les aperçus sociaux tags: [Sujet, Autre] --- Votre contenu commence ici. ``` ## Ce que vous obtenez ### Fonctionnalités de contenu - **Flux RSS** — généré automatiquement à `/rss.xml` - **Plan du site** — auto-généré via `@astrojs/sitemap` - **Balises SEO** — Open Graph, Twitter Cards, URLs canoniques - **Mode sombre** — commutateur à trois positions (Clair / Sombre / Système) - **Pages catégories et tags** — archives organisées par sujet ### Fonctionnalités développeur - **TypeScript strict** — composants et utilitaires entièrement typés - **Content Collections** — Markdown type-safe avec validation du frontmatter - **Tailwind CSS v4** — tokens de design via `@theme` - **Vitest + Playwright** — tests unitaires et E2E intégrés au CI - **Cloudflare Pages** — URLs de prévisualisation automatiques - **Google Analytics** — optionnel, isolé dans un Web Worker Partytown ## Philosophie de design La simplicité visuelle de ce thème est intentionnelle, mais elle diffère de la simplicité d'ingénierie. Sous le capot, le thème gère de nombreuses préoccupations : typographie responsive, contrastes de couleurs accessibles, structure HTML sémantique correcte et attention portée à l'expérience de lecture. Bon design signifie design invisible. Quand vous lisez un article sur ce thème sans même le remarquer — c'est que le design fonctionne exactement comme prévu. Bonne écriture.