💡 J’ai créé une app IA RGPD en 1h avec Symfony

le 2 avril 2026

Aujourd’hui, beaucoup de développeurs utilisent l’IA pour générer du code.

La question que l'on traite ici est la suivante :

👉 Comment transformer une idée en système exécutable ?

Et c’est normal.

Parce qu’on a appris à :

• coder des features
• écrire des fonctions
• brancher des API

Mais pas à :

structurer une idée pour qu’elle puisse être exécutée

Chez Darkwood, on ne commence jamais par le code.

On commence par une étape beaucoup plus fondamentale :

👉 le raisonnement

Dans cet article, on va voir concrètement :

1. Comment transformer une idée en unité exploitable
2. Comment utiliser l’IA pour exécuter cette idée
3. Comment appliquer ça dans un vrai projet : SketchUp Shape

🧠 1. Une idée n’est pas du code

Quand tu penses :

“Créer une application”

ton réflexe de dev, c’est souvent :

“ok, je vais coder une API, une base de données, etc.”

👉 Mauvais point de départ.

Une idée, ce n’est pas encore quelque chose que tu peux exécuter.

C’est juste :

👉 une intention floue

💡 Le bon modèle mental

Chez Darkwood, on considère que :

👉 une idée = une tâche

Pas plus, pas moins.

Exemple

“Créer une application”

devient :

Task: create_app

Ça peut paraître trivial.

Mais c’est un changement important :

👉 Tu ne penses plus en “projet” 👉 Tu penses en unités exécutables

⚙️ Pourquoi cette méthode fonctionne : Church, Turing, et l’idée comme unité exécutable

On pourrait croire que “prompter une IA” est un sujet récent, presque purement pratique, lié à l’actualité des LLM.

En réalité, le problème est beaucoup plus ancien.

Quand un développeur prend une idée et cherche à la transformer en système exécutable, il se heurte toujours à la même question :

comment passer d’une intention abstraite à une forme que la machine peut réellement traiter ?

C’est exactement le type de question qui se trouve à la racine de l’informatique théorique.

Dans un précédent article Darkwood - Create a Lambda Interpreter in PHP - nous avions déjà exploré cette frontière entre :

• l’idée d’un calcul
• et son exécution réelle par une machine

Cet article partait du λ-calcul d’Alonzo Church, puis le reliait à la machine de Turing, en rappelant un point fondamental :

le λ-calcul et la machine de Turing sont deux modèles équivalents du calcul

Autrement dit :

• Church donne un modèle conceptuel
• Turing donne un modèle d’exécution

Et c’est exactement ce qui nous intéresse ici.

🧠 Church : avant l’exécution, il faut une forme pensable

Alonzo Church ne part pas d’une machine. Il part d’un problème beaucoup plus profond :

qu’est-ce qu’une fonction ?

et plus largement :

qu’est-ce qu’un calcul ?

Le λ-calcul répond à cela avec une idée radicale :

tout calcul peut être exprimé comme abstraction et application de fonctions

Dans ce modèle :

• une fonction est une transformation
• une valeur peut être transmise à une autre fonction
• et l’évaluation consiste à appliquer des fonctions les unes aux autres

C’est la racine théorique de beaucoup de choses que nous utilisons aujourd’hui sans y penser :

• la programmation fonctionnelle
• le currying
• les closures
• les combinators
• les transformations pures
• les DSL

Dans l’article sur l’interpréteur lambda en PHP, cette idée était présentée de manière très concrète : on partait d’une expression, on la tokenisait, on la parsait, on construisait un AST, puis on l’évaluait.

Autrement dit :

avant qu’un système exécute quelque chose, il faut d’abord qu’il comprenne une forme

C’est exactement le point qui nous intéresse pour l’IA.

Quand tu donnes à un LLM une phrase comme :

Create a house

tu ne lui donnes pas encore une exécution. Tu lui donnes une forme abstraite, une intention, une demande encore insuffisamment structurée.

Et c’est là que l’intuition de Church devient utile pour nous.

Traduction développeur

Quand on parle d’idée dans cet article, on ne parle pas d’inspiration vague ou de brainstorming.

On parle déjà d’une abstraction manipulable.

Autrement dit :

une idée doit devenir une unité sur laquelle un système peut raisonner

C’est pour cela que, chez Darkwood, nous faisons un premier déplacement mental :

une idée n’est pas encore du code

une idée est déjà une transformation en attente

Ou, dit autrement :

une idée est une tâche potentielle

⚙️ Turing : une fois la forme posée, il faut l’exécuter

Church formalise le calcul du côté de l’abstraction. Turing, lui, répond à une autre question :

à quoi ressemble une machine capable de réaliser ce calcul ?

Sa réponse est célèbre :

• une bande mémoire
• une tête de lecture
• un état courant
• des règles de transition

La puissance du modèle ne vient pas de sa complexité, mais au contraire de sa simplicité.

Une machine de Turing lit une case, tient compte de son état, applique une règle, écrit éventuellement quelque chose, puis avance.

C’est un modèle extrêmement simple, mais suffisant pour raisonner sur ce qu’une machine peut faire.

Ce qui nous intéresse ici, ce n’est pas d’enseigner toute la théorie des automates. C’est de récupérer une intuition très concrète :

un système exécutable a besoin d’unités lisibles

et d’un mécanisme clair pour passer d’un état à l’autre

C’est là que le lien avec le travail moderne sur les idées, les tâches, et les agents IA devient très concret.

🔁 Ce que Church et Turing nous apprennent pour travailler avec une IA

Le point essentiel, c’est le suivant :

• Church nous apprend à penser le calcul comme transformation
• Turing nous apprend à penser le calcul comme exécution structurée

Quand on assemble les deux, on obtient une manière beaucoup plus saine de travailler avec l’IA.

On cesse de penser :

“je vais demander du code au modèle”

Et on commence à penser :

“je vais lui donner une unité de travail structurée, qu’il pourra transformer, puis qu’un autre système pourra exécuter”

C’est exactement ce que nous faisons chez Darkwood.

🧩 Traduction Darkwood : une idée devient une tâche

À ce stade, on peut simplifier le modèle sans le trahir.

Voici la traduction qui nous sert de base :

| Concept théorique | Interprétation Darkwood | | ----------------- | ---------------------------- | | Abstraction | Idée structurée | | Fonction | Transformation | | Case mémoire | Tâche | | Bande | Liste / pile de tâches | | Lecture | Exécution | | Transition | Passage d’un état à un autre |

Cela nous donne une règle simple :

une idée devient une tâche

une tâche devient une unité lisible

une unité lisible peut être exécutée

C’est ce changement de perspective qui compte.

Parce que tant qu’une idée reste seulement dans ta tête, elle est inutilisable par le système :

• ni ton terminal
• ni ton IDE
• ni ton LLM
• ni ton orchestrateur

ne peuvent travailler dessus correctement.

Il faut donc lui donner une forme.

💡 L’idée comme unité de calcul

C’est ici que notre méthode prend tout son sens.

Quand on dit :

Créer une application

ce n’est pas encore un système. Ce n’est pas encore une architecture. Ce n’est pas encore un prompt exploitable.

Mais ce n’est pas non plus “rien”.

C’est déjà :

une unité de calcul à expliciter

Chez Darkwood, nous la faisons passer par une étape de nomination et de réduction.

Par exemple :

Task: create_app

ou

Task: generate_sketchup_shape

À partir de là, la machine - ou le système d’agents - ne manipule plus seulement une phrase humaine. Elle manipule une tâche identifiable.

Et à partir du moment où tu peux identifier une tâche, tu peux :

• la stocker
• la relire
• la reproduire
• la transmettre
• la découper
• la paralléliser
• l’orchestrer

C’est cela, le vrai changement.

🧠 Pourquoi c’est si utile pour un développeur

Un développeur a souvent tendance à sauter directement à l’implémentation :

• créer un dossier
• installer Symfony
• brancher une API
• écrire une commande

Mais si l’idée initiale n’a pas été correctement modélisée, tout le reste devient instable.

On obtient alors ce que beaucoup vivent avec les LLM aujourd’hui :

• des prompts flous
• des sorties floues
• des structures fragiles
• des projets qui “marchent”, mais sans cohérence

La théorie de Church et Turing nous rappelle quelque chose de très simple :

la qualité de l’exécution dépend de la qualité de la représentation initiale

Autrement dit :

si tu veux mieux prompter une IA, il faut d’abord mieux représenter ton idée

Et c’est précisément ce que nous allons faire dans la suite avec SketchUp Shape :

• partir d’une intention
• la convertir en tâche
• la structurer
• la transformer en design
• puis seulement en code

🧭 La règle à retenir

S’il fallait condenser toute cette section en une seule phrase, ce serait celle-ci :

une idée utile pour l’IA n’est pas une inspiration

c’est une abstraction suffisamment claire pour devenir une tâche exécutable

Et c’est là que Church et Turing cessent d’être de la théorie lointaine.

Ils deviennent un modèle pratique pour le développeur moderne :

• Church t’aide à penser la forme
• Turing t’aide à penser l’exécution
• Darkwood t’aide à relier les deux

📚 Exemple concret

Tu as plusieurs idées :

- créer une app
- construire une API
- générer un modèle 3D

👉 Tu peux les représenter comme une stack :

Stack:
- create_app
- build_api
- generate_model

Et là, tout devient plus simple :

tu peux traiter chaque tâche une par une

ou

en parallèle

⚡ 2. Ton cerveau fonctionne déjà comme ça

Tu n’as pas besoin d’apprendre un nouveau système.

👉 Tu l’utilises déjà.

🧠 Cas simple : tâches différentes

Task A: répondre à un message
Task B: installer un package

👉 Aucun lien 👉 Tu peux passer de l’un à l’autre facilement

⚠️ Cas compliqué : tâches similaires

Task A: coder une API
Task B: refactor la même API

👉 Là, ça devient dur

Pourquoi ?

• même contexte
• même variables mentales
• mêmes fichiers

👉 Résultat :

• confusion
• erreurs
• fatigue

💥 Ce que ça implique

Ton cerveau :

• a une mémoire limitée
• gère mal trop de contexte
• sature vite

👉 Donc :

tu ne peux pas gérer beaucoup de tâches complexes en même temps

🧩 3. Le vrai problème : la reproductibilité

Une tâche n’a de valeur que si tu peux :

• la retrouver
• la relancer
• la partager

👉 Sinon, elle reste dans ta tête 👉 et elle disparaît

🧠 Approche Darkwood

On introduit une idée simple :

👉 une tâche = un pointeur

Concrètement

• tu écris ta tâche dans Joplin
• elle a un ID
• cet ID devient ton “pointeur”

Et ensuite :

• dans ton terminal → tu fais référence à cette tâche
• dans ton IDE → pareil
• dans ton IA → pareil

👉 Résultat :

tu manipules le même objet, partout

💡 Ce que ça change

Tu ne dis plus :

“je vais bosser sur mon idée”

Tu dis :

“je vais exécuter cette tâche”

Et ça, c’est beaucoup plus puissant.

⚙️ 4. L’IA : pas un outil magique, un système d’exécution

Aujourd’hui, beaucoup de devs utilisent l’IA comme ça :

• “génère-moi une fonction”
• “écris-moi une classe”
• “corrige ce bug”

👉 Ça marche.

Mais tu restes dans une logique :

réactive

🧠 Approche Darkwood

On change complètement la perspective :

👉 l’IA devient un système d’exécution

🏗 On modélise comme une entreprise

Plutôt que des “agents magiques”, on utilise une structure simple :

👤 Toi (humain)

• tu définis l’intention
• tu poses le problème

🧠 Architecte IA

• il comprend ton intention
• il découpe en tâches
• il décide comment organiser le système

⚙️ Agents

• ils exécutent
• ils produisent du code
• ils transforment les données

💡 Règle clé

👉 Le prompt = ton intention

Si ton prompt est flou :

👉 le système est flou

Si ton prompt est structuré :

👉 le système devient structuré

🔥 Exemple

❌ Mauvais prompt :

“Generate a house”

✅ Bon prompt :

“Create a structured architectural design of a house,
with walls, roof, proportions and constraints,
then generate SketchUp Ruby code from it”

👉 Là, tu donnes :

• une direction
• une structure
• un objectif clair

🧠 Ce que tu dois retenir

👉 Tu n’as pas besoin d’être meilleur en code

👉 Tu dois devenir meilleur en :

• structuration
• intention
• orchestration

Et c’est exactement ce qu’on va appliquer maintenant avec :

👉 SketchUp Shape

🚀 5. Application concrète : SketchUp Shape

Projet : 👉 https://github.com/matyo91/sketchup-shape

🎯 Objectif

Transformer :

“Create a house”

en :

👉 script Ruby exécutable dans SketchUp

🧱 Pourquoi SketchUp ?

• outil de modélisation 3D
• API Ruby documentée : → SketchUp Ruby API
• extensible (plugins, scripts)

🎓 Contexte

J’ai personnellement appris SketchUp avec Sébastien Maison (YouTube)

👉 Ici, l’objectif n’est pas d’utiliser leur IA :

→ IA SketchUp officielle

👉 Mais de construire notre propre système

Parfait - on va rendre cette partie plus concrète, plus ancrée terrain, plus “dev”, tout en intégrant :

• SketchUp (contexte réel)
• Sébastien Maison (preuve sociale)
• API Ruby (levier technique)
• IA locale (différenciation forte)

⚙️ 6. Pipeline : de l’idée au modèle 3D (concret)

Avant d’aller plus loin, on va prendre un cas réel.

👉 Ici, on ne parle pas d’une API abstraite 👉 On parle de générer un objet 3D dans SketchUp

🧱 Petit contexte : pourquoi SketchUp ?

SketchUp est un outil de modélisation 3D très utilisé :

• architecture
• design
• prototypage

Personnellement, j’ai découvert SketchUp grâce à Sébastien Maison, avec qui j’ai suivi une formation.

👉 J’y ai modélisé une maison “à la main”

Et c’est là que l’idée est venue :

👉 “Et si je pouvais générer ça directement avec du code ?”

⚠️ Pourquoi ne pas utiliser l’IA native de SketchUp ?

SketchUp propose déjà de l’IA :

👉 SketchUp AI

Mais ici, ce n’est pas le sujet.

👉 Nous sommes développeurs.

👉 On veut :

• comprendre
• contrôler
• automatiser

Donc on passe par :

👉 l’API Ruby de SketchUp

🧠 L’entrée technique

Pour ça, SketchUp expose :

• Documentation développeur
• API Ruby

👉 Concrètement :

tu écris du Ruby comme ça :

model = Sketchup.active_model
entities = model.entities

Et tu construis :

• des faces
• des volumes
• des groupes

🧩 Ressources utilisées

Pour rendre l’IA plus fiable, j’ai utilisé :

• Ruby API Stubs 👉 pour donner au LLM une vision claire des objets disponibles

• Exemples officiels 👉 pour comprendre les patterns réels

Et si tu veux aller plus loin :

👉 Extensions SketchUp → tu peux packager ton code en plugin

⚠️ Prérequis important

Pour exécuter du Ruby :

👉 tu dois utiliser la version desktop :

SketchUp Pro Trial

👉 La version web ne permet pas ça (ou très limité)

🔁 Pipeline Darkwood (appliqué)

Maintenant qu’on a le contexte, voici le pipeline réel :

Intention
   ↓
Design (LLM #1)
   ↓
Code (LLM #2)
   ↓
SketchUp

🧠 Étape 1 : intention

Tu pars d’une idée simple :

bin/console app:generate-shape "Create a house"

👉 Rien de plus.

🧱 Étape 2 : design (LLM #1)

Ici, l’IA ne code pas.

👉 Elle réfléchit

Elle agit comme un architecte :

{
  "type": "house",
  "structure": {
    "walls": {...},
    "roof": {...}
  }
}

👉 Elle décide :

• des proportions
• des éléments
• de la structure

⚙️ Étape 3 : code (LLM #2)

Ensuite seulement :

👉 une deuxième IA transforme ce plan en code

model.start_operation('House', true)
...
model.commit_operation

👉 Elle agit comme un développeur :

• elle utilise l’API SketchUp
• elle construit la géométrie

⚠️ 7. Pourquoi 2 LLM (et pas 1)

C’est une des parties les plus importantes.

❌ Approche naïve

idée → code

👉 Ce que tu obtiens :

• incohérent
• imprévisible
• difficile à corriger

✅ Approche Darkwood

idée → design → code

👉 Tu sépares :

• 🧠 le quoi
• ⚙️ le comment

💡 C’est exactement comme dans une équipe :

• architecte → décide
• développeur → implémente

🧠 8. Le problème réel rencontré

Quand j’ai lancé :

Create a house

👉 Résultat :

• techniquement valide
• mais visuellement… faux

👉 Ce n’était pas une maison

❌ Pourquoi ?

Parce que l’IA a fait ça :

“une maison = des formes”

👉 Elle a empilé :

• des cubes
• un toit
• sans logique

💥 Le vrai problème

L’IA ne comprend pas :

• la gravité
• les proportions
• l’usage réel

👉 Elle ne comprend pas :

ce qu’est une maison

🧠 Correction apportée

On a introduit une couche :

👉 design structuré

Au lieu de :

{ "parts": [...] }

On force :

{
  "type": "house",
  "foundation": {...},
  "walls": {...},
  "roof": {...},
  "constraints": {
    "symmetry": true,
    "alignment": "centered"
  }
}

👉 Résultat :

• cohérence
• stabilité
• rendu crédible

⚙️ 10. Stack technique

🧱 Backend

• Symfony 8
• Symfony AI
• darkwood/navi

👉 installation :

composer require darkwood/navi

🧠 IA locale (RGPD)

• Mistral 3
• Ollama

👉 tout tourne en local

⚖️ Pourquoi c’est important

• pas d’API externe
• pas de fuite de données
• contrôle total

👉 tu construis un système :

RGPD compliant by design

⚙️ 11. Commandes

🧠 LLM local

ollama pull ministral-3:8b
ollama serve

⚙️ Génération

bin/console app:generate-shape "Create a house"

Options utiles

-o house.rb        # sauvegarde du script
--spec design.json # sauvegarde du design
-v                 # debug complet

🧠 12. Ce que tu dois vraiment retenir

❌ Ce n’est pas :

• “comment utiliser une IA”

✅ C’est :

👉 comment structurer une idée pour qu’une IA puisse l’exécuter

🔁 Modèle final

idée
 → tâche
 → design
 → code
 → exécution

🚀 Conclusion

Le futur du développement n’est pas :

écrire plus de code

Mais :

structurer des idées et orchestrer leur exécution

👉 Chez Darkwood :

on ne cherche pas à aller plus vite

on cherche à être plus juste

• Poster un commentaire