# Pourquoi j'ai choisi un fichier HTML plutôt que Next.js pour ma landing page

* * *

Il y a un anti-pattern que je vois partout dans le monde de la data : utiliser **Apache Spark pour traiter 10 000 lignes de CSV**. Le framework impressionne sur le papier, il est dans le CV, alors on l'utilise — même quand un simple script pandas ferait le travail en 2 secondes avec zéro infrastructure.

J'ai failli faire la même erreur en construisant ce blog. Réflexe de dev : `npx create-next-app@latest loko-labs`.

Un framework React, un pipeline de build, des dépendances à maintenir. Tout ça pour... afficher du texte et appeler une API.

J'ai pris du recul. Et j'ai appliqué à mon propre projet le même principe que je défends pour les pipelines de données : **la bonne complexité pour le bon problème.**

* * *

### Ce que la landing page devait faire

Avant de choisir un outil, un ingénieur pose la question du besoin réel. Voici la spec complète :

*   Présenter Loko Labs et son positionnement
    
*   Afficher les derniers articles publiés sur Hashnode
    
*   Être hébergée gratuitement
    
*   Se mettre à jour automatiquement à chaque publication
    
*   Zéro maintenance dans le temps
    

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text"><strong>VERDICT</strong> — C'est une page statique avec une seule source de données externe. La complexité d'un framework est injustifiée.</div>
</div>

### L'arbitrage : Next.js vs HTML statique

Voici les trade-offs concrets que j'ai évalués :

| Critères | Next.js/Framework | HTML Statique |
| --- | --- | --- |
| Complexité | Build pipeline, webpack, 200+ packages | <mark class="bg-yellow-200 dark:bg-yellow-500/30">Zéro, un seul fichier</mark> |
| Dépendances | Vulnérabilités à surveiller en continu | <mark class="bg-yellow-200 dark:bg-yellow-500/30">Aucune</mark> |
| Déploiement | Vercel, CI/CD, variables d'environnement | <mark class="bg-yellow-200 dark:bg-yellow-500/30">Github Pages, drag &amp; drop</mark> |
| Maintenance | MàJ régulières de packages | <mark class="bg-yellow-200 dark:bg-yellow-500/30">Aucune</mark> |
| Performance | Bundle JS chargé avant le 1er pixel | <mark class="bg-yellow-200 dark:bg-yellow-500/30">HTML rendu immédiatement</mark> |
| Données | SSG ou ISR à configurer | <mark class="bg-yellow-200 dark:bg-yellow-500/30">Fetch API, toujours frais</mark> |
| Portabilité | Vendor lock-in Vercel/framework | <mark class="bg-yellow-200 dark:bg-yellow-500/30">Fichier HTML portable partout</mark> |

Next.js aurait été le bon choix avec un routing complexe ou du rendu serveur. Mais pour une landing page qui appelle une API ? C'est ce qu'on appelle du **over-engineering**.

### La stack retenue : simple, solide, portable

Voici exactement ce que j'ai utilisé - et c'est très exactement uniquement ça :

```shell
loko-labs/
    index.html    <- tout le code (HTML, CSS, JS en un seul fichier)

# Hébergement : GitHub Pages (gratuit, illimité pour les repos publics)
# Données : API GraphQL Hashnode (appelée côté client au chargement de la page)
# Domaine :  à venir, mais un fichier CNAME dans le repo suffit à le gérer
```

### L'intégration Hashnode en 15 lignes

L'API GraphQL de Hashnode est publique. On a pas besoin de clé API pour lire les articles :

```javascript
const query = `
    query {
        publication(host: "votreusername.hashnode.dev") {
            posts(first: 6) {
                edges {
                  node { title brief slug url publishedAt tags { name } }
                }
            }
        }
    }
`;

const res = await fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query })
});

const { data } = await res.json();
// -> articles frais a chaque visite, sans redéploiement
```

**Résultat :** à chaque visite, les articles sont **toujours à jour** sans aucun redéploiement. Pas de webhook, pas de GitHub Action, juste un **fetch**.

* * *

### Le vrai sujet : l'ingénierie, c'est choisir

Dans le monde de la data, on souffre d'un biais systématique vers la complexité. On déploie Kubernetes parce que Netflix le fait. On adopte des frameworks parce qu'ils sont populaires, pas parce qu'ils résolvent notre problème.

Un bon ingénieur data ne se demande pas *"quel outil impressionnant puis-je utiliser ?"* Il se demande **"quel est le minimum viable pour que ça tienne en production ?"**

<div data-node-type="callout">
<div data-node-type="callout-emoji">⚡</div>
<div data-node-type="callout-text"><strong>PRINCIPE LOKO LABS </strong>— La complexité est un coût. Chaque dépendance, chaque service supplémentaire est une surface de panne potentielle. Sois capable de justifier chaque couche de ta stack.</div>
</div>

Ce principe s'applique exactement à un pipeline de données :

*   **Airflow** pour un job cron quotidien ? → Un simple script Python suffit.
    
*   **Kafka** pour 100 événements/jour ? → Une table PostgreSQL avec polling suffit.
    
*   **dbt** pour 3 transformations simples ? → Des vues SQL directement dans la base suffisent.
    
*   **Next.js** pour une landing page statique ? → Un fichier HTML suffit.
    

> La bonne stack n'est pas celle qui impressionne — c'est celle qui **résiste dans le temps** avec le moins d'efforts de maintenance possible.

* * *

### Et la suite ?

Cette landing page va évoluer avec Loko Labs :

*   Domaine custom `lokolabs.dev` → un fichier `CNAME` dans le repo
    
*   Compteur d'articles dynamique dans le hero
    
*   Score Lighthouse target : **100/100**
    

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text"><strong>NOTE</strong> — Quand le blog grandira et que le besoin de pages multiples ou de SEO avancé se fera sentir, là je migrerai vers Astro ou Next.js. Pas avant. C'est ça, l'ingénierie.</div>
</div>

* * *

### En résumé

> **La complexité est une dette.**

Chaque framework, chaque service que tu ajoutes est une obligation de maintenance future. La vraie expertise d'un ingénieur, ce n'est pas de savoir utiliser les outils complexes — c'est de savoir **quand ne pas les utiliser.**

La landing page de Loko Labs a été construit avec un fichier HTML, l'API Hashnode, et GitHub Pages. Ça tourne, c'est gratuit, ça ne tombera pas en panne à 2h du matin. **Solide comme un Loko.**

* * *

Tags : #DataOps #Architecture #WebDev #Hashnode #GitHubPages #BonnesPratiques