Générer une application complète avec Gemini CLI : fantasme ou réalité ?

Peut-on vraiment générer une application web complète avec FastAPI, React et base de données en moins d'une heure grâce à l'IA ? Gemini CLI le prétend. Test en conditions réelles avec un cahier des charges précis et... quelques surprises à la clé. Retour d'expérience sans filtre.

Cet article a été mis à jour le 6 août 2025 ; il prend 23 minutes à lire et comporte 5553 mots.

J’ai posé une ques­tion toute sim­ple à Gem­i­ni 2.5 Flash : À quoi sert Gem­i­ni CLI ? Voici sa réponse, très… promotionnelle :

Gemini CLI (Command Line Interface) est un utilitaire en ligne de commande open-source développé par Google qui intègre la puissance des modèles d'IA Gemini directement dans votre terminal. Il est conçu pour simplifier et automatiser les tâches courantes des développeurs et améliorer leur productivité.

Voici les principales fonctions et utilités de Gemini CLI :

Compréhension et analyse de code :
Il peut explorer et comprendre votre base de code, même les projets très volumineux (jusqu'à 1 million de tokens de contexte).
Il peut répondre à des questions sur le code en langage naturel (par exemple, "Explique comment fonctionne la fonction de connexion").
Il aide à visualiser le code en générant des diagrammes de flux ou d'autres représentations.

Assistance au développement et débogage :
Il peut vous aider à corriger des bogues et des problèmes directement depuis votre terminal.
Il est capable de refactoriser le code pour l'améliorer.
Il génère des tests unitaires pour votre code.
Il peut insérer du code ou modifier des fichiers selon vos instructions.
Il aide à trouver les variables inutilisées ou les types incorrects.

Automatisation et gestion de projet :
Il peut automatiser la génération de projets.
Il facilite la gestion des versions et les déploiements.
Il peut créer des rapports Markdown des modifications apportées.
Il peut interagir avec des systèmes d'entreprise comme SAP et Celonis.
Il peut être invoqué de manière non interactive dans des scripts pour automatiser des tâches.

Interaction en langage naturel :
Vous pouvez interagir avec Gemini CLI en utilisant des invites en langage naturel, sans avoir à apprendre de commandes spécifiques.
Il maintient une "mémoire" de votre session, ce qui permet de poser des questions de suivi sans répéter le contexte.

Fonctionnalités avancées et extensibilité :
Il prend en charge le "Model Context Protocol (MCP)" et d'autres extensions.

Vous pouvez personnaliser les invites et les instructions pour adapter Gemini à vos besoins spécifiques.
Il offre des outils intégrés comme la lecture/écriture de fichiers, l'exécution de commandes shell, la recherche Google, etc.
Il permet de sauvegarder et de reprendre des conversations.

Des commandes spéciales (/stats, /memory, /tools, etc.) fournissent des informations sur l'utilisation et le contexte.

En résumé, Gemini CLI est un assistant IA puissant et polyvalent qui apporte la capacité de comprendre, générer et modifier du code directement dans votre environnement de terminal, améliorant considérablement l'efficacité des développeurs. Il est même disponible gratuitement avec des limites d'utilisation généreuses via un compte Google personnel.

Et bien sûr, la ques­tion suiv­ante était : Est-il pos­si­ble de génér­er une appli­ca­tion com­plète avec ? Ques­tion à laque­lle j’ai eu une réponse claire :

Oui, il est tout à fait possible de générer une application complète avec Gemini CLI. C'est même l'une de ses capacités les plus impressionnantes et un des objectifs de sa conception.

Voici comment Gemini CLI y parvient et pourquoi il est un "game-changer" pour la création d'applications :

Compréhension du contexte étendu (1 million de tokens) : Contrairement à d'autres outils qui traitent le code par petits morceaux, Gemini CLI peut ingérer et comprendre des bases de code entières, même très volumineuses. Cela lui permet d'avoir une vision globale du projet et de générer du code cohérent et intégré.

Interaction en langage naturel : Vous n'avez pas besoin d'écrire des commandes complexes. Vous pouvez simplement lui dire ce que vous voulez : "Crée-moi une application de gestion de tâches simple avec HTML, CSS et JavaScript", ou "Développe une API backend en Python pour gérer des utilisateurs avec FastAPI". Gemini CLI interprétera vos requêtes et agira en conséquence.

Scaffolding de projet (génération de structure) : Gemini CLI peut initialiser la structure d'un nouveau projet, créer les dossiers, les fichiers de base et les configurations nécessaires pour le framework ou la technologie que vous spécifiez. Par exemple, il peut créer un projet Flask, React, Node.js, etc.

Génération de code incrémentale et itérative : Vous pouvez commencer par une demande générale, puis affiner l'application par étapes. Par exemple :
"Crée une application web simple pour afficher des données."
"Ajoute une fonctionnalité pour filtrer les données."
"Améliore l'interface utilisateur pour qu'elle soit plus moderne."
"Ajoute une base de données pour stocker les informations."Gemini CLI maintient le contexte de la conversation, ce qui lui permet d'itérer sur le code existant et d'apporter des modifications intelligentes.

Utilisation des outils intégrés et des extensions (MCP) : Gemini CLI peut utiliser des outils comme la lecture/écriture de fichiers, l'exécution de commandes shell, la recherche web, etc., pour accomplir ses tâches. De plus, avec le "Model Context Protocol (MCP)", il peut s'intégrer à des serveurs externes pour étendre encore plus ses capacités, par exemple en se connectant à des bases de données ou à d'autres services.

Découpage des tâches complexes : Pour générer une application complète, Gemini CLI ne se contente pas de "jeter" du code. Il peut décomposer la tâche en étapes plus petites, comme analyser les exigences, concevoir l'architecture, créer la structure des fichiers, écrire les composants principaux, ajouter le style et les interactions, tester l'application et documenter le code.

Génération de tests et débogage : Non seulement il peut générer du code, mais il peut aussi générer des tests unitaires pour le code qu'il produit, et même vous aider à identifier et corriger les bogues.

Automatisation du déploiement (avec les bons outils) : Bien que Gemini CLI lui-même ne soit pas un outil de déploiement, il peut vous aider à générer les configurations nécessaires (comme des Dockerfiles) et même interagir avec des services cloud (comme Google Cloud Run) pour déployer l'application une fois qu'elle est prête.

En somme, Gemini CLI agit comme un assistant de développement intelligent qui peut prendre en charge l'ensemble du cycle de vie de la création d'une application, de la conception initiale à la génération du code et même au débogage, le tout depuis votre terminal et en utilisant le langage naturel. C'est un outil puissant pour accélérer le développement et prototyper rapidement des idées.

Alors bien sûr, j’ai voulu tester. Pas ques­tion d’un Hel­lo World. Je voulais un vrai test, avec une app déjà en pro­duc­tion comme référence. 

Ayant récem­ment dévelop­pé une appli qui récupère des doc­u­ments, les envoie à un LLM pour génér­er un résumé et en extraire des notions, j’ai voulu voir si cette IA fai­sait mieux que moi. En même temps, je ne suis pas un expert en Python, j’ai donc pen­sé que si je pou­vais le faire, lui pou­vait aussi.

Le cahier des charges

J’avais l’ap­pli, j’en voulais une ver­sion sim­pli­fiée. J’ai donc gardé les élé­ments essen­tiels, avec une petite spé­ci­ficité : je voulais utilis­er Alloy­DB Omni, la base de don­nées com­pat­i­ble Post­greSQL de Google.

Le prompt pour Gemini CLI

L’un des points essen­tiels quand on utilise l’IA, est de bien définir son prompt. Ce n’est d’ailleurs pas un trait dis­tinc­tif de l’IA, quel que soit le con­texte, pos­er une ques­tion claire et pré­cise aug­mente for­cé­ment les chances d’obtenir une réponse claire et pré­cise. J’ai donc repris mon cahi­er des charges et je l’ai trans­posé en instruc­tions claires pour Gem­i­ni Cli. Je l’ai d’abord rédigé en anglais, mais au final, je l’ai traduit, pour être cer­tain de bien définir chaque point :

#Fonctionnalités :

Les utilisateurs peuvent télécharger un fichier (.txt, .rtf, .docx, .odt, .md)
Le backend extrait le contenu texte brut en utilisant des bibliothèques appropriées aux formats (python-docx, odfpy, etc.)
Le texte extrait est envoyé à un LLM (via une API compatible OpenAI sur DeepInfra, Fireworks ou OpenRouter) pour :
Résumé (environ 5 à 10 lignes)
Extraction de mots clés (10 à 20 concepts pertinents, en minuscules, retournés en JSON)

#Gestion des fichiers :
Le fichier téléchargé d'origine doit être stocké sur le serveur avec des métadonnées
L'utilisateur doit pouvoir télécharger ou consulter le fichier d'origine depuis l'interface utilisateur

#Pile technologique :
Frontend : React avec TailwindCSS (propre et minimaliste)
Backend : FastAPI (Python), asynchrone lorsque cela est approprié
Base de données : AlloyDB (compatible PostgreSQL)
Déploiement : Docker (configuration multi-service si nécessaire)
Clé API : configurable via un fichier .env

#Contraintes :
Pas d'OCR, pas de prise en charge des PDF ni des images
Pas de cartographie des relations entre les mots clés
Code modulaire, bien commenté
Inclure une recherche basée sur les mots clés dans le frontend

#Configuration de Git et de l'environnement :
Initialiser un dépôt Git et pousser sur GitHub
Ajouter un fichier .gitignore qui exclut les artefacts de construction, les environnements virtuels et les fichiers sensibles (par exemple, .env, __pycache__, node_modules, etc.)
Créer un fichier .env.sample qui inclut toutes les variables d'environnement attendues (par exemple, LLM_API_KEY, LLM_API_BASE)
Ne pas valider le fichier .env réel

La demande était à mon avis suff­isam­ment claire pour que l’IA me génère l’ap­pli demandée.

Et après une ving­taine de min­utes, et après avoir répon­du à quelques ques­tions, et validé un cer­tain nom­bre d’ac­tions, j’avais effec­tive­ment une appli­ca­tion com­plète à dis­po­si­tion. Com­plète, oui, mais util­is­able, non.

Et Gem­i­ni CLI n’avait pas respec­té mon cahi­er des charges :

• il n’avait pas ini­tial­isé d’en­vi­ron­nement Git.
• Il n’avait pas (et c’est logique) créé de fichi­er .gitignore, ni de fichi­er .env.sample.
• Mais il n’avait pas non plus répon­du à ma demande con­cer­nant le SGBD à utilis­er : il a sans sour­ciller rem­placé Alloy­DB Omni par PostgreSQL.

Alors, ce n’est pas une hérésie, vu que Alloy­DB Omni est 100% com­pat­i­ble PostreSQL. Mais quand je demande un ristret­to, je ne veux pas un espres­so. Ni d’un café allongé. Les deux sont com­pat­i­bles, oui. Mais les per­for­mances, sur de gros datasets, ne sont pas les mêmes. Et Post­greSQL néces­site pgvector pour la ges­tion d’une base vec­to­rielle, quand Alloy­DB la gère nativement.

Il ne faut pas oubli­er non plus qu’Al­loy­DB Omni est une base de don­nées Google, je pen­sais donc que ce point ne lui poserait pas prob­lème. Comme quoi…

Je lui ai fourni un sec­ond prompt pour qu’il cor­rige ces points :

# Requête de correction Gemini CLI — Projet "Readwise Light"

## Problèmes constatés
Le projet généré ne respecte pas plusieurs consignes pourtant explicites. Merci de corriger les points suivants de manière prioritaire et rigoureuse.

## 1. Remplacer PostgreSQL par **AlloyDB**
> L’image utilisée est `postgres:15-alpine`, ce qui ne respecte pas la consigne.

### Ce qui est attendu :
```yaml
services:
  db:
    image: google/alloydbomni:latest
    container_name: alloydb
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=readwise
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
```

**Référence DockerHub** :
[https://hub.docker.com/r/google/alloydbomni/tags]

## 2. Ajouter un fichier `.env` et un `.env.sample`
> Aucun fichier `.env` n’a été généré malgré la mention explicite de cette exigence.

### Exemple de `.env` attendu :

```env
DB_HOST=db
DB_PORT=5432
DB_NAME=readwise
DB_USER=xxxxx
DB_PASSWORD=**********
SECRET_KEY=xxxxxxx
API_URL=https://xxxxx.ai/api/v1/xxx/xxx
API_KEY=***************
MODEL=qwen/qwen3-30b-a3b:free
```

### Et un `.env.sample` (sans clés privées) :

```env
DB_HOST=db
DB_PORT=5432
DB_NAME=readwise
DB_USER=xxxxx
DB_PASSWORD=**********
SECRET_KEY=xxxxxxx
API_URL=https://xxxxxxx.ai/api/v1/xxx/xxx
API_KEY=***************
MODEL=xxxxxxxxxxxx```

### Pense à ajouter `.env` dans `.gitignore`

Alors oui, Gem­i­ni CLI a cor­rigé une par­tie des points demandés. Sans pour autant créer de référen­tiel Git. Je n’ai pas insisté, j’ai créé mon dépôt, j’ai com­mit­té et basta.

Et au delà de ses points de détail (oui, il faut savoir être indul­gent), son appli n’é­tait pas fonc­tion­nelle. J’ai dû repass­er der­rière lui pour obtenir ce que je voulais :

Je lui ai fourni un ensem­ble clé / url dans le cahi­er des charges ini­tial pour pour l’ac­cès au LLM, il s’est empressé de créer une clé fic­tive et de chang­er l’url d’ac­cès à l’API.

Par con­tre rien à redire au niveau de la struc­ture elle-même :

readwise_light/
├──  README.md                    # Documentation principale
├──  docker-compose.yml           # Configuration Docker Compose
├──  Dockerfile.backend           # Image Docker backend
├──  Dockerfile.frontend          # Image Docker frontend
├──  .gitignore                   # Fichiers ignorés par Git
│
├──  backend/                     # Application backend
│   ├──  requirements.txt         # Dépendances Python
│   ├──  app/                     # Code source backend
│   │   ├──  main.py              # Point d'entrée FastAPI
│   │   ├──  models.py            # Modèles de données SQLModel
│   │   ├──  crud.py              # Opérations base de données
│   │   ├──  db.py                # Configuration base de données
│   │   ├──  text_extractor.py    # Extraction de texte
│   │   └──  llm.py               # Intégration LLM
│   └──  uploads/                 # Stockage des fichiers uploadés
│       └──  README.md
│
└──  frontend/                    # Application frontend
    ├──  package.json             # Dépendances Node.js
    ├──  vite.config.js           # Configuration Vite
    ├──  tailwind.config.js       # Configuration TailwindCSS
    ├──  postcss.config.js        # Configuration PostCSS
    ├──  eslint.config.js         # Configuration ESLint
    ├──  index.html               # Template HTML principal
    ├──  src/                     # Code source frontend
    │   ├──  main.jsx             # Point d'entrée React
    │   ├──  App.jsx              # Composant principal
    │   ├──  App.css              # Styles spécifiques
    │   ├──  index.css            # Styles globaux
    │   └──  assets/              # Ressources statiques
    └──  public/                  # Fichiers publics
        └──  vite.svg

Et son code est rel­a­tive­ment bien écrit et doc­u­men­té, comme on peut le voir ci-dessous (fichi­er backend/app/main.py) :

from fastapi import FastAPI, UploadFile, File, Depends, HTTPException
from fastapi.responses import FileResponse
from sqlmodel import Session
from . import crud, models, text_extractor, llm
from .db import engine, create_db_and_tables
import shutil
import os
import json
from typing import List

app = FastAPI()

def get_db():
    with Session(engine) as session:
        yield session

@app.on_event("startup")
def on_startup():
    create_db_and_tables()

@app.post("/upload/")
async def upload_file(file: UploadFile = File(...), db: Session = Depends(get_db)):
    # Create a directory to store uploaded files
    upload_dir = "uploads"
    os.makedirs(upload_dir, exist_ok=True)

    # Save the uploaded file
    file_path = os.path.join(upload_dir, file.filename)
    with open(file_path, "wb") as buffer:
        shutil.copyfileobj(file.file, buffer)

    # Extract text from the file
    try:
        content = text_extractor.extract_text(file_path)
    except ValueError as e:
        raise HTTPException(status_code=400, detail=str(e))

    # Get summary and keywords from LLM
    llm_response = llm.get_summary_and_keywords(content)

    # Parse the llm_response to get summary and keywords
    try:
        # Find the start of the JSON block
        json_start_index = llm_response.find("```json")
        if json_start_index == -1:
            raise ValueError("JSON block not found in the LLM response")

        summary = llm_response[:json_start_index].strip()
        json_str = llm_response[json_start_index + 7:].strip().strip("`")
        keywords = json.loads(json_str)
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"Error parsing LLM response: {e}")


    # Create document object
    doc = models.Document(
        filename=file.filename,
        content=content,
        summary=summary,
    )
    doc.set_keywords(keywords)
    db_doc = crud.create_document(db, doc)

    return db_doc

@app.get("/documents/", response_model=List[models.Document])
def get_documents(db: Session = Depends(get_db)):
    return crud.get_all_documents(db)

@app.get("/documents/{doc_id}", response_model=models.Document)
def get_document(doc_id: int, db: Session = Depends(get_db)):
    doc = crud.get_document(db, doc_id)
    if doc is None:
        raise HTTPException(status_code=404, detail="Document not found")
    return doc

@app.get("/download/{doc_id}")
def download_file(doc_id: int, db: Session = Depends(get_db)):
    doc = crud.get_document(db, doc_id)
    if doc is None:
        raise HTTPException(status_code=404, detail="Document not found")
    
    file_path = os.path.join("uploads", doc.filename)
    if not os.path.exists(file_path):
        raise HTTPException(status_code=404, detail="File not found")

    return FileResponse(file_path, filename=doc.filename)

@app.get("/search/")
def search_documents(query: str, db: Session = Depends(get_db)):
    # A simple search implementation
    docs = crud.get_all_documents(db)
    results = []
    for doc in docs:
        if query.lower() in doc.content.lower() or any(query.lower() in k.lower() for k in doc.get_keywords()):
            results.append(doc)
    return results

@app.get("/")
def read_root():
    return {"Hello": "World"}

Le code est plutôt pro­pre et lis­i­ble dans l’ensemble, avec une archi­tec­ture mod­u­laire (sépa­ra­tion en mod­ules crud, models, text_extractor, llm, etc.).

Les points positifs

• Sépa­ra­tion des respon­s­abil­ités : les fonc­tions de traite­ment (LLM, extrac­tion de texte, base de don­nées) sont bien isolées.
• Util­i­sa­tion cor­recte de Depends() et de Session() avec SQLMod­el : le pat­tern de dépen­dance est propre.
• Véri­fi­ca­tions robustes :
  • Exis­tence du fichier
  • Retour du LLM parsé avec fall­back si le JSON est mal formé
• Upload de fichiers et per­sis­tance : tout est fonc­tion­nel, logique, clair.
• Con­forme aux bonnes pra­tiques FastAPI (par exem­ple l’usage de @app.on_event("startup") pour ini­ti­er la base de données).

Les points à améliorer

Quelques failles de robustesse (fichiers upload­és, pars­ing LLM, val­i­da­tion des entrées), mais rien de bloquant.

Pour une appli­ca­tion « pro­duc­tion ready », il faudrait :

• isol­er le pars­ing LLM dans une fonc­tion solide avec tests unitaires,
• ajouter un log­ger propre,
• met­tre en place une véri­fi­ca­tion MIME et un hash de fichi­er pour éviter les doublons.

Mais dans l’é­tat, ce n’é­tait pas demandé, on n’est plus dans le con­texte ini­tiale­ment défini.

Par con­tre, j’avais hâte de voir le résul­tat, on peut avoir un code sub­lime, mais qui ne fait pas ce qu’on lui demande, j’ai donc procédé au…

Test de l’application en ligne de commande

C’est là que tout a com­mencé à se gâter : rien n’é­tait fonc­tion­nel. Et j’ai passé près de deux heures à met­tre tout en ordre, en faisant appel à la con­sole Gem­i­ni CLI mais surtout à d’autres LLM (chat­G­PT et Claude d’An­throp­ic) en sit­u­a­tion de blocage.

Voici une liste non exhaus­tive des points sur lesquels j’ai dû intervenir :

• L’ap­pel au LLM – bien que je lui ai indiqué qu’il fal­lait pass­er par openrouter.ai pour appel­er le LLM, Gem­i­ni CLI appelait directe­ment l’API d’Ope­nAI : platform.openai.com – j’ai réécrit la fonc­tion incrim­inée, après avoir ten­té de le lui faire faire
• J’ai dû ajouter python-multipart dans requirements.txt et curl dans le Dockerfile
• Forcer la sor­tie en json pour obtenir un résul­tat inter­prétable. A nou­veau, réécri­t­ure par­tielle d’un script.

Une fois ces point réglés, le texte a pu être uploadé et traité en lançant curl -F "file=@README.md" http://localhost:8000/upload/.

Sor­tie json cor­recte, et enreg­istrement en base de don­nées effectué.

Mais pas encore de…

Test depuis un navigateur

L’af­faire se corse : impos­si­ble d’ac­céder à l’ap­pli via le nav­i­ga­teur. En rem­plaçant "dev": "vite" par "dev": "vite --host 0.0.0.0" dans packages.json, le prob­lème ini­tial est réglé.

J’ac­cède enfin à l’ap­pli­ca­tion. Tout n’est pas rose pour autant. Tout ce que j’ob­tiens, c’est un sub­lime mes­sage d’erreur :

[plugin:vite:css] [postcss] It looks like you're trying to use tailwindcss directly as a PostCSS plugin. The PostCSS plugin has moved to a separate package, so to continue using Tailwind CSS with PostCSS you'll need to install @tailwindcss/postcss and update your PostCSS configuration. /app/src/index.css:undefined:null at We (/app/node_modules/tailwindcss/dist/lib.js:35:2121) at LazyResult.runOnRoot (/app/node_modules/postcss/lib/lazy-result.js:361:16) at LazyResult.runAsync (/app/node_modules/postcss/lib/lazy-result.js:290:26) at LazyResult.async (/app/node_modules/postcss/lib/lazy-result.js:192:30) at LazyResult.then (/app/node_modules/postcss/lib/lazy-result.js:436:17) Click outside, press Esc key, or fix the code to dismiss. You can also disable this overlay by setting server.hmr.overlay to false in vite.config.js.

Et là, Gem­i­ni CLI échoue lam­en­ta­ble­ment quand je lui demande de cor­riger en lui indi­quant l’er­reur. Il rame, tourne à vide pen­dant près de 10 min­utes, je le dés­ac­tive et je tente avec un autre out­il : black​box​.ai. Qui va me réécrire une bonne par­tie du code fron­tend. Sans pour autant régler le prob­lème. npm aura eu rai­son de Gem­i­ni CLI et de Blackbox.

Je finis par deman­der une réécri­t­ure com­plète du fron­tend à Gem­i­ni CLI :

Tu es un générateur d'application web. Tu dois produire un frontend statique en HTML/CSS/JavaScript (sans framework, sans bundler) qui remplace entièrement un frontend existant dans une application FastAPI.

Contraintes :
- Le backend FastAPI existe déjà et expose une route POST /extract qui accepte un fichier (.txt, .md, .docx, .rtf, .odt) et retourne un JSON avec :
  - summary : une chaîne (résumé)
  - keywords : une liste de chaînes
- Le frontend doit proposer :
  1. un input file,
  2. envoyer ce fichier via fetch à /extract en POST,
  3. afficher le résumé et les mots-clés reçus, dans des conteneurs séparés.
- Tu dois générer uniquement des fichiers purs :
  - frontend/index.html
  - frontend/style.css
  - frontend/script.js
- Aucune dépendance externe ni outil ("npm", "webpack", etc.).
- L’ensemble doit être responsive, clair visuellement et ergonomique.
- Ajoute un feedback utilisateur (chargement, erreurs).
- Présente les trois fichiers complets de façon structurée (avec balises appropriées).

Donne également les instructions pour intégrer ces fichiers dans le projet FastAPI existant (montage `StaticFiles`).

Et là, rien à dire, à part un petit bug visuel, Gem­i­ni CLI fait bien ce qu’on lui demande, mais en deux temps et sans pou­voir com­pléter cer­taines tâch­es. Il ne parvient pas par exem­ple à réécrire un fichi­er Dockerfile.frontend cor­rect, je dois pren­dre la main. Mais j’ob­tiens l’in­ter­face demandée, et je réus­sis à analyser un fichi­er. Pour les besoins du test, j’ai pris une ver­sion texte de l’ar­ti­cle sur le grand gâchis numérique, voici le résumé servi par Qwen 3 30B A3B :

L'article explore la sous-utilisation de l'intelligence artificielle (IA) par les PME et TPE malgré l'accessibilité des outils technologiques. Il souligne les barrières culturelles, financières et techniques qui empêchent leur adoption, comparant la situation à une 'fracture numérique' où les grandes entreprises dominent les ressources et les compétences. Les solutions open source comme spaCy ou Hugging Face sont citées comme des alternatives abordables, mais leur mise en œuvre reste complexe. L'auteur appelle à une démocratisation réelle via des formations, un accompagnement et des outils simplifiés, avant que les PME ne soient marginalisées dans un futur proche.

Il me ressort égale­ment les mots / expres­sions clé :

intelligence artificielle, automatisation, PME, TPE, fracture numérique, GAFAM, BATX, outils open source, analyse des avis clients, analyse de sentiment, formation, coût, complexité, démocratisation, écart technologique, innovation, exploitation des données, transformation numérique, barrières d’adoption, ghetto numérique

Le ren­du est cor­rect – il n’y a que « Analyse en cours… » qui tourne en per­ma­nence, rien de désastreux :

Bilan de l’expérience

Alors, Gem­i­ni CLI est-il capa­ble de créer une appli­ca­tion à par­tir d’un cahi­er de charges rel­a­tive­ment précis ?

On va dire que créer une appli­ca­tion com­plète avec cet out­il est pos­si­ble – mais pas sans effort.

Voici les prin­ci­paux enseigne­ments que j’en retire :

Les points positifs :

• L’outil com­prend rapi­de­ment les inten­tions exprimées en lan­gage naturel.
• Il génère une struc­ture de pro­jet cohérente et bien modulaire.
• Le code est pro­pre, bien com­men­té, et suit générale­ment les bonnes pratiques.
• Il gère les échanges itérat­ifs (prompt → code → cor­rec­tion) de manière fluide.

Les limites et frustrations :

• Il ne respecte pas tou­jours scrupuleuse­ment le cahi­er des charges, même clair et bien formaté.
• Des oub­lis réguliers sur des élé­ments clés comme .gitignore, .env.sample, init Git, ou même le choix du SGBD.
• Il prend par­fois des déci­sions “raisonnables” à ma place (comme rem­plac­er Alloy­DB par Post­greSQL sans prévenir).
• Il ne rend pas une appli­ca­tion prête à l’emploi : des ajuste­ments manuels restent indispensables.

Test de reprise de contexte et modifications a posteriori

L’un des aspects les plus cri­tiques d’un assis­tant IA de développe­ment est sa capac­ité à repren­dre le tra­vail sur du code exis­tant après une décon­nex­ion. Pour tester cette fonc­tion­nal­ité, j’ai volon­taire­ment fer­mé la con­sole Gem­i­ni CLI et atten­du le lende­main pour deman­der des mod­i­fi­ca­tions sur l’ap­pli­ca­tion générée.

Reconnaissance du projet existant

Temps de reprise de con­texte : moins de 3 minutes

En relançant Gem­i­ni CLI dans le réper­toire du pro­jet, l’outil a immé­di­ate­ment analysé la struc­ture de fichiers et le code exis­tant. Sans que j’aie besoin de lui rap­pel­er le con­texte ou les spé­ci­fi­ca­tions ini­tiales, il m’a pro­posé un plan d’ac­tion détail­lé pour les amélio­ra­tions demandées.

Points posi­tifs de cette reprise :

• Iden­ti­fi­ca­tion cor­recte de l’ar­chi­tec­ture exis­tante (FastAPI + React + AlloyDB)
• Recon­nais­sance des points prob­lé­ma­tiques que j’avais cor­rigés manuelle­ment la veille
• Propo­si­tion de mod­i­fi­ca­tions cohérentes avec la struc­ture mod­u­laire mise en place

Un cas concret : la réécriture du frontend

Face aux prob­lèmes insur­monta­bles avec le fron­tend React/Vite ini­tial, j’ai demandé à Gem­i­ni CLI de réécrire com­plète­ment cette par­tie en HTML/CSS/JavaScript pur. L’outil a par­faite­ment compris :

• Les routes back­end exis­tantes (POST /extract)
• Le for­mat de don­nées atten­du (JSON avec summary et keywords)
• Les con­traintes tech­niques (pas de frame­work, pas de bundler)

Résul­tat : Une inter­face fonc­tion­nelle générée rapi­de­ment, avec seule­ment quelques ajuste­ments mineurs néces­saires (comme la cor­rec­tion du fichi­er Dockerfile.frontend).

Bilan de la reprise de contexte

Ver­dict : très convaincant

La capac­ité de Gem­i­ni CLI à repren­dre le tra­vail sur du code exis­tant est l’un de ses points forts les plus mar­quants. Le con­texte éten­du de 1 mil­lion de tokens se traduit par une vraie effi­cac­ité pra­tique pour la main­te­nance et l’évo­lu­tion de code, posi­tion­nant l’outil comme un véri­ta­ble « parte­naire de développe­ment » capa­ble d’as­sur­er une con­ti­nu­ité dans le temps.

Comparaison avec d’autres outils

J’ai déjà util­isé Claude ain­si que chat­G­PT pour dévelop­per des appli­ca­tions en ligne. Le code pro­duit par Gem­i­ni Cli n’est ni plus ni moins val­able que celui pro­duit par ses con­cur­rent, même si – en ver­sion gra­tu­ite, Claude ne per­met pas d’aller très loin, et si chat­G­PT se perd sou­vent en cours de route. Il est évi­dent que la lim­ite de con­texte de Gem­i­ni CLI n’y est pas pour rien : 1 mil­lion de tokens, ce n’est pas rien, surtout pour une petit pro­jet. Mais les reproches faits aux deux autres out­ils sont à relativiser :

• si chat­G­PT se perd sou­vent, son approche est plus solide, et son code tout aus­si bien structuré
• si Claude n’est pas envis­age­able dans sa ver­sion gra­tu­ite, le peu que j’ai pu voir de et out­il me donne envie de tester la ver­sion payante

Con­cer­nant Black­box, je n’ai pas réus­si à me faire une opin­ion. Il a un intérêt, certes, mais il ne m’a pas per­mis d’aller au-delà de ce que Gem­i­ni Cli a pu faire.

Analyse du coût/bénéfice temporel

Il a fal­lu moins d’une demi heure à Gem­i­ni CLI pour génér­er une appli­ca­tion com­plète. Impar­faite, mais com­plète. En comp­tant les 2 à 3 heures de réglages sup­plé­men­taires, et la rédac­tion du cahi­er des charges, on n’at­teint pas les 4 heures. Com­bi­en de temps m’au­rait-il fal­lu pour arriv­er au même résul­tat, en par­tant de zéro, si j’avais dû tout coder par moi-même ?

En résumé :

Gem­i­ni CLI est un assis­tant IA puis­sant pour accélér­er le pro­to­ty­page et la mise en route d’un pro­jet, mais il ne rem­place pas un développeur humain. Il offre un bon gain de temps pour génér­er la base d’une appli­ca­tion, mais néces­site tou­jours un œil cri­tique, des retouch­es, et une phase de test rigoureuse.

C’est un out­il promet­teur, mais encore impar­fait pour du “Code as a Ser­vice” automa­tisé de bout en bout. 

Et moi, j’ai appris de cette expéri­ence. Pour l’essentiel…

Les leçons que j’en ai tiré

La précision du cahier des charges ne garantit pas le respect à 100%

Même avec des spé­ci­fi­ca­tions détail­lées et explicites (Alloy­DB, fichiers .env, init Git), l’IA prend des « lib­ertés » qu’elle juge raisonnables. Il faut s’at­ten­dre à devoir recen­tr­er l’outil sur les exi­gences non négociables.

Gemini CLI est excellent pour le scaffolding, moins pour les finitions

Gem­i­ni CLI excelle pour génér­er une struc­ture cohérente et du code pro­pre, mais les détails d’in­té­gra­tion (con­fig­u­ra­tion Dock­er, dépen­dances spé­ci­fiques, URLs d’API) néces­si­tent sys­té­ma­tique­ment une inter­ven­tion humaine.

Le contexte étendu est un vrai game-changer

La capac­ité à repren­dre le tra­vail le lende­main en moins de 3 min­utes et à com­pren­dre l’ar­chi­tec­ture exis­tante dif­féren­cie net­te­ment Gem­i­ni CLI des autres out­ils IA.

Prévoir du temps de debug même sur du code « propre »

Il ne faut pas con­fon­dre code bien struc­turé et code fonc­tion­nel. Les 2 heures de cor­rec­tions ne sont pas du temps per­du mais un investisse­ment prévis­i­ble dans tout pro­jet généré par IA.

L’IA a ses propres « convictions techniques »

Post­greSQL vs Alloy­DB, choix d’URLs d’API… L’outil fait des sub­sti­tu­tions qu’il con­sid­ère comme équiv­a­lentes. Il faut explicite­ment insis­ter sur les choix non négociables.

Adopter une approche itérative payante

Par­tir d’une demande glob­ale puis affin­er par étapes fonc­tionne mieux que d’es­say­er de tout spé­ci­fi­er d’un coup. L’ex­em­ple du fron­tend HTML/CSS/JS pur en est la preuve.

Garder des alternatives sous la main

Chat­G­PT et Claude ont été néces­saires pour déblo­quer cer­taines sit­u­a­tions. Gem­i­ni CLI n’est pas omnipo­tent, avoir un plan B évite les blocages prolongés.

Le ROI est positif malgré les corrections

Même avec les cor­rec­tions néces­saires, le gain de temps reste sig­ni­fi­catif par rap­port à un développe­ment from scratch, surtout pour le pro­to­ty­page rapide.

Gem­i­ni CLI est donc un excel­lent accéléra­teur de développe­ment à con­di­tion d’ac­cepter son rôle d’as­sis­tant per­fectible plutôt que de développeur autonome.

Voici le work­flow que je recom­mande pour exploiter Gem­i­ni CLI de façon fiable :

graph TD
A[Spécifications techniques] --> AA[Prompt clair]
AA --> B{Génération initiale}
B --> C[Scaffolding]
C --> D[Revue manuelle critique]
D --> E{Corrections IA}
E --> F[Tests intensifs]
F --> G[Déploiement]
G --> H[Documentation]

Le mot de la fin

En résumé, Gem­i­ni CLI impres­sionne par la puis­sance de son moteur de généra­tion, mais reste per­fectible dans le respect strict d’un cahi­er des charges com­plexe. L’outil est promet­teur pour des pro­to­types ou MVPs, mais néces­site encore une super­vi­sion humaine pour les pro­jets sérieux.

Le ver­dict : Ni fan­tasme ni réal­ité absolue, mais un out­il de tran­si­tion vers une nou­velle façon de dévelop­per où l’hu­main reste indis­pens­able pour la vision, la cohérence et la qual­ité finale.

Aller plus loin

Cette appli­ca­tion con­stitue une base solide pour de nom­breuses évo­lu­tions. Voici quelques pistes d’amélio­ra­tion que vous pour­riez explorer :

Fonctionnalités avancées

Analyse séman­tique poussée : Rem­plac­er la recherche par mots-clés par une recherche vec­to­rielle basée sur des embed­dings. Cela per­me­t­trait de retrou­ver des doc­u­ments par sim­i­lar­ité séman­tique plutôt que par cor­re­spon­dance exacte.

Mul­ti-LLM et com­para­i­son : Inté­gr­er plusieurs mod­èles (Claude, GPT, Lla­ma) pour génér­er dif­férents résumés du même doc­u­ment et laiss­er l’u­til­isa­teur choisir le plus per­ti­nent, ou même fusion­ner les analyses.

Clas­si­fi­ca­tion automa­tique : Ajouter un sys­tème de caté­gori­sa­tion automa­tique des doc­u­ments par domaine (tech­nique, juridique, mar­ket­ing, etc.) avec un mod­èle de clas­si­fi­ca­tion pré-entraîné.

His­torique et ver­sion­ing : Con­serv­er l’his­torique des analy­ses d’un même doc­u­ment pour suiv­re l’évo­lu­tion des résumés selon les dif­férentes ver­sions du fichier.

Améliorations techniques

Traite­ment asyn­chrone : Implé­menter une queue Redis + Cel­ery pour traiter les gros fichiers en arrière-plan avec noti­fi­ca­tion en temps réel du statut.

Cache intel­li­gent : Éviter de retraiter des doc­u­ments iden­tiques en util­isant un sys­tème de hash MD5 et de mise en cache des résultats.

API robuste : Ajouter le ver­sion­ing (/v1/, /v2/), la lim­i­ta­tion de taux, la val­i­da­tion avancée des fichiers et un sys­tème de mon­i­tor­ing des performances.

Visualisation et analytics

Dash­board de visu­al­i­sa­tion : Créer des graphiques sur les mots-clés les plus fréquents, l’évo­lu­tion tem­porelle des con­cepts, ou encore un nuage de mots interactif.

Export enrichi : Pro­pos­er des exports en PDF avec résumés for­matés, CSV des méta­don­nées, ou encore des for­mats com­pat­i­bles avec Obsidian/Notion pour l’in­té­gra­tion dans des sys­tèmes de ges­tion de connaissances.

Vers la production

Authen­tifi­ca­tion et rôles : Sys­tème d’u­til­isa­teurs avec JWT, ges­tion des per­mis­sions et espaces de tra­vail collaboratifs.

Sécu­rité ren­for­cée : Scan antivirus des fichiers upload­és, val­i­da­tion stricte des types MIME, et sys­tème de back­up automatique.

Expérimentations IA avancées

RAG con­ver­sa­tion­nel : Trans­former l’ap­pli­ca­tion en assis­tant capa­ble de répon­dre à des ques­tions sur l’ensem­ble des doc­u­ments upload­és en util­isant le con­texte des fichiers analysés.

Résumés adap­tat­ifs : Ajuster automa­tique­ment la longueur et le style du résumé selon le type de doc­u­ment détec­té (rap­port tech­nique vs arti­cle de blog).

Extrac­tion d’en­tités struc­turées : Iden­ti­fi­er et extraire automa­tique­ment les per­son­nes, lieux, dates, organ­i­sa­tions men­tion­nées avec des out­ils comme spa­Cy ou des mod­èles Trans­form­ers spécialisés.

Le défi ultime ? Deman­der à Gem­i­ni CLI d’im­plé­menter ces amélio­ra­tions une par une. Ce serait un excel­lent moyen de tester ses capac­ités d’évo­lu­tion sur du code exis­tant tout en enrichissant pro­gres­sive­ment l’application !

Le dépôt est acces­si­ble sur Github : https://​github​.com/​p​c​e​s​c​a​t​o​/​r​e​a​d​w​i​s​e​_​l​i​ght

Sen­tez vous libre de le récupér­er, de con­tribuer, d’en faire un fork… et de com­menter cet article.

Pas­cal CESCATO

Je ne me con­tente pas de refor­muler des com­mu­niqués ou de dérouler des specs. Je teste, je creuse, je démonte quand il faut – parce qu’un sujet mal com­pris est un sujet mal écrit. J’écris avec les mains dans le cam­bouis, sans sim­pli­fi­er à out­rance ni recracher du mar­ket­ing. Mon truc, c’est de ren­dre clair sans trahir, lis­i­ble sans liss­er. Et non, je ne “fais pas du con­tenu”. Pas pour faire du con­tenu, en tout cas.