Pourquoi j’ai décidé de pousser Pocket Architect (et ce que j’ai compris sur l’IA)

Il y a quelques semaines, j’ai commencé à écrire ici.

Sans stratégie particulière.
Sans objectif précis.

Simplement pour documenter ce que je construisais :

• mes réflexions
• mes blocages
• mes avancées

Le point de départ

À l’origine, Pocket Architect n’était pas un produit.

C’était une exploration.

Je voulais comprendre jusqu’où je pouvais aller avec l’IA, et surtout :

Est-ce que cela pouvait réellement aider à structurer un projet technique ?

Pas générer du code.
Pas reproduire ce qui existe déjà.

Mais réfléchir.

Une limite très claire

Les outils actuels sont performants.

Mais en les utilisant sur des cas concrets, une limite est apparue :

Les réponses sont souvent justes, mais rarement directement exploitables.

Pourquoi ?

Parce qu’il manque :

• du contexte métier
• une logique d’architecture claire
• une anticipation des contraintes

En résumé : cela répond, mais cela ne décide pas.

Le déclic

Le problème ne vient pas de l’IA.

Le problème vient de l’absence de structure autour.

Un modèle seul ne suffit pas à produire une réflexion technique fiable.

Il faut :

• un cadre
• une logique
• une méthode de décision

Ce qui a changé

J’ai commencé à structurer :

• formaliser mes règles d’architecture
• clarifier mes prises de décision
• identifier des patterns réutilisables

Et j’ai continué à partager cette démarche.

Une réaction inattendue

Progressivement, des retours sont arrivés :

• des messages
• des échanges
• des personnes confrontées aux mêmes problématiques

Et surtout, un intérêt réel pour cette approche.

La décision

À partir de là, la direction est devenue évidente.

Pocket Architect ne serait plus une exploration.

Ce sera un produit.

Pas un outil générique.
Pas un assistant supplémentaire.

Mais un système capable de :

• structurer un projet
• orienter des décisions
• éviter des erreurs coûteuses

Le projet aujourd’hui

Je construis actuellement un système d’architecture basé sur :

• l’expérience terrain
• des règles concrètes
• des cas réels

Ce système sera connecté à un LLM (probablement OpenAI dans un premier temps), mais avec un cadre strict.

L’objectif

Ce projet n’a pas vocation à remplacer.

Il vise à améliorer la phase la plus critique d’un projet :

La réflexion avant construction.

Conclusion

Ce projet n’était pas planifié.

Mais il répond à un besoin réel :

• des projets mal structurés dès le départ
• des décisions prises trop rapidement
• des coûts qui explosent ensuite

La suite

Je vais continuer à documenter :

• les choix techniques
• la construction du système
• les tests réels avec l’IA
• les limites rencontrées

Si tu travailles sur un projet digital, une question simple :

Est-ce que tu es en train de construire,
ou est-ce que tu es en train de structurer ?