Par l'IA
L'IA comme outil.
Les plateformes et le code en dessous de tout — pourquoi on livre en semaines, pas en trimestres.
Construire. Mesurer. Publier.
L'IA en prod, c'est plus dur qu'en labo. Je documente l'écart.
Apuna. Notes de terrain.
Je fais tourner l'IA en prod dans une boîte de services industriels — agents de formation vocale, évaluateurs LLM, conformité AI Act en co-gestion. Ce sont mes questions de recherche pour mon Dr.-Ing. prévu. Ce site, c'est où mes méthodes et mes fails atterrissent pendant que le taf continue.
Voir sur GitHub →Thèse de terrain
La plupart des projets IA que j'ai vus dans le service industriel s'arrêtent au proof-of-concept. Voici ce que j'ai observé chez ceux qui ne s'arrêtent pas.
Le pilote a tourné. La production, jamais. L'écart est presque toujours le même — et ce n'est pas l'algorithme.
Le constat
Ce que je vois avant qu'un projet ne s'arrête
- —Des projets IA qui s'arrêtent au proof-of-concept — et n'atteignent jamais la production.
- —Des plateformes achetées de bonne foi — sans support, sans SLA quand le premier vrai problème arrive.
- —Des données machine sur OPC-UA, Modbus, MQTT que personne ne traduit en décisions.
- —De grands cabinets de conseil qui envoient un account manager — et personne qui connaît l'atelier.
- —Pas d'équipe IA en interne — et pas envie du prochain lock-in fournisseur.
- —Des outils brillants en démo qui s'effondrent au premier quart de production.
La méthode
Ce qui fonctionne vraiment
La même personne planifie et construit.
L'approche
Des capteurs aux décisions — en production
Je commence par la donnée capteur. Connecter, traduire, rendre actionnable. Construire des systèmes qui prennent en charge de vraies tâches opérationnelles — sur le terrain, pas seulement dans un pilote.
L'engagement
Maintenu après la livraison
Je reste impliqué après la passation. Pas comme un service managé — comme un système documenté, open source, que tu possèdes et peux faire tourner. Je suis joignable quand le cas limite apparaît.
Pourquoi ça compte
Ce que le constat enseigne
- ›La même personne planifie et construit. Pas de passation entre celui qui comprend le système et celui qui le maintient.
- ›Ingénierie mécanique, pas seulement Python. Je traduis entre le modèle et l'atelier — dans les deux sens.
- ›Ton infrastructure, sans lock-in. Neutre vis-à-vis des fournisseurs, tourne sur tes propres systèmes. Pas de boîte noire — tes données et ta propriété intellectuelle restent tiennes.Chaque changement consigné et validé par un humain.
- ›La preuve terrain avant les décisions d'architecture. Je lance la première intégration sur des données de production réelles avant de m'engager sur une conception. Les contraintes n'apparaissent qu'en présence du vrai système.
Une conversation. Un problème concret. Une évaluation honnête.
apuna.dev · Allemagne
Whitepaper
Read the whitepaper / as PDFAI you can audit and run yourself — how I build it.
01 — Comment je bosse
Comment je bosse — et où je m'arrête.
L'IA, c'est pas mon pitch. C'est mon outil de tous les jours. Infra, interlocuteur de travail, levier — et je sais exactement où ça s'arrête.
Avec l'IA
L'IA comme partenaire.
Un humain et une IA qui raisonnent ensemble vers un outcome que ni l'un ni l'autre n'atteindrait seul. Je reste dans la boucle. No handoff.
Grâce à l'IA
L'IA comme porte d'entrée.
Du taf qui n'existait pas il y a deux ans — nouvelles questions, nouveaux rôles, nouvelle vitesse. J'essaie de capter quand c'est exactement ça qui se passe.
Malgré l'IA
L'IA comme limite.
Certaines choses restent humaines. Pas à cause d'une policy, mais parce que je le choisis à chaque fois. Je choisis délibérément où l'IA n'a rien à faire.
Je documente ce que le terrain m'apprend — échecs inclus.
07 — L'équipe
Ma façon de travailler
Je travaille seul — avec une équipe d'IA pour réfléchir, concevoir et mettre à l'épreuve. Pas de réseau de freelances, pas d'équipe commerciale, pas d'investisseurs. Ce que tu lis sur ce site vient d'un seul praticien, relu et validé avant publication.
MES AGENTS IA
Et l'équipe IA avec laquelle je travaille
Ce sont des personas IA — pas des membres humains de l'équipe. Chaque résultat qu'ils produisent est relu et validé par une personne avant publication.
La Présidente est la constante — continuité et vision à long terme ; l'équipe opérationnelle rédige, conçoit, construit et met à l'épreuve, avec un conseiller qui élargit le cercle. C'est moi qui prends chaque décision.
Équipe principale
Conseillers
02 — Méthode
Quatre étapes. Toujours dans cet ordre — parce que l'ordre, c'est la réflexion.
Analyse de processus
La plupart des ops perdent des heures chaque semaine sur des workarounds que personne n'a choisis. Je commence là où le taf se passe — avec les gens qui le portent. Avant de choisir un outil, je cartographie la friction, je trace les contournements, je trouve le seul changement qui en débloque dix autres.
En savoir plus
Capture de connaissance
Ce que les seniors savent vit nulle part par écrit. Je le fais remonter, je le structure, je le rends accessible — pour que le prochain tech à 2h du mat' ait la réponse que le précédent a mis 20 ans à gagner.
En savoir plus
Automatisation
Tes experts arrêtent de bruler des heures payées sur des steps qu'une machine fait mieux. Cette capacité revient dans le taf que seulement eux peuvent faire. J'automatise ce qui demande pas de décision humaine. Le jugement reste où il doit être.
En savoir plus
Intégration IA
L'équipe prend de meilleures décisions, plus vite — parce que l'IA arrive en dernier, sur un process déjà clean et de la knowledge déjà structurée. Elle affûte les gens qui ont construit le process ; elle les remplace pas.
En savoir plus
Devlog
Méthodes et fails documentés au fil de l'eau.
Je garde un running log de ce sur quoi je bosse — l'approche, ce qui a pété, ce que je ferais différemment. Pas de retros polies. Des notes au plus près du travail, pendant que les détails piquent encore.
Lire le devlogMis à jour au fil du taf
03 — Open by Default
Tout ce que je construis est ouvert. Tout ce que j'apprends est publié.
Le code est Apache-2.0. Méthodes documentées. Ratés à côté des réussites. Pas une charte — comment la recherche reste honnête.
Apache-2.0
Tout ce que je construis pour ce taf est Apache-2.0. Read it, fork it, run it, build on it. Sans conditions, sans lock-in progressif, sans astérisque open-core qui cache le vrai produit.
Méthodes, pas juste résultats
Je publie l'approche autant que le résultat. Un résultat sans méthode = une anecdote. Le devlog et les résultats de recherche montrent les deux : le chemin et la destination.
Fails documentés
Ce qui marche pas compte autant que ce qui marche — parfois plus. J'écris les fails pour qu'un peer qui lit ça dans un an refasse pas les mêmes erreurs.
La knowledge reste ouverte
Rien de ce que j'apprends dans ce taf disparaît derrière un paywall ou un retainer. Si c'est utile, ça appartient au public. C'est tout le sens de faire ça en open.
05 — Comment je pense la responsibility
Les règles selon lesquelles je bosse. Zéro ambiguïté sur qui décide.
J'ai réfléchi soigneusement à où l'output de l'IA s'arrête et où le jugement humain commence. Ce sont pas des avertissements légaux. Ce sont les principes selon lesquels je conçois vraiment.
L'humain décide — toujours.
Chaque output avec lequel je bosse finit par atteindre un point de décision humain. Je conçois pour ça. L'IA aide ; elle décide pas. C'est un principe que j'applique avant que ce soit une exigence.
La responsabilité suit la conception.
L'EU AI Act trace une ligne claire entre celui qui construit un système d'IA et celui qui le déploie. Je prends cette ligne au sérieux — pas comme une contrainte réglementaire, mais comme une question de conception. C'est la question de recherche pour mon doctorat prévu.
“Je porte le design. Tu portes la décision.”
06 — À propos
Qui je suis.
Background ingénieur, field practice
M.Sc. Wirtschaftsingenieurwesen, TH Mannheim, 2015. Je pilote l'implémentation IA dans une orga de services industriels — voice training agents, LLM evaluators, AI Act compliance dans une boîte avec co-gestion. Les contraintes de ce secteur sont mon quotidien, pas un brief que j'ai lu la veille.
Recherche en planification
Je bosse sur un Dr.-Ing. à la Hochschule Heilbronn et la TH Mannheim, début prévu Q3 2026. Question de recherche : comment les LLM-based training systems sont conçus, et comment l'adoption tech dans le service industriel marche actually. Design Science Research + mixed methods.
Pourquoi je publish
Les questions que je rencontre chaque semaine sont pas juste les miennes. Des praticiens en position similaire portent les mêmes problèmes — et les réponses utiles sont rarement consignées quelque part. Ce site corrige ça. Le code est Apache-2.0. Prends-le.
Ce que je construisEn développement
Petits outils. Vraies décisions. Documentés ici.
Journal de petits outils ciblés que je construis pour tester des idées et les documenter en public. Chacun commence par une décision qui vaut le coup — pas une liste de fonctionnalités. Voir l'étude de cas.
- 01
Trouver la décision qui vaut le coup
Chaque outil commence par une vraie question — actuellement répondue au feeling ou par un spreadsheet à laquelle personne ne fait vraiment confiance.
- 02
Chopper la data
J'identifie quelle data existe actually, je la récupère, je vérifie si elle est assez solide pour construire dessus. Pas de données, pas d'outil.
- 03
Construire petit
Une décision, une interface — rien de plus. La contrainte, c'est le point — le scope creep, c'est comment les outils arrêtent de marcher.
- 04
Documenter
Chaque outil vient avec un compte rendu : ce que j'ai construit, pourquoi, ce que je ferais différemment. Devlog = audit trail.
Premier outil
Commodity Intelligence
Identifie automatiquement les cinq matières premières qui comptent le plus en achats directs, pondérées par la valeur ajoutée, puis suit les marchés spot et futures pour que les décisions d'achat et de couverture soient fondées sur des faits — pas sur l'intuition.
Aide à la décision pour les équipes achats — pas un conseil financier.
Try the toolDeuxième outil
Component Setup Guide
Nomme un composant, dépose optionnellement une URL de page produit. L'outil récupère les docs, identifie la variante exacte et fonde chaque instruction de câblage, config et code sur ce qui a été trouvé — avec des refus explicites là où la doc manque.
Expérimental · modèles libres · vérifier contre la fiche fabricant avant de câbler.
Try the toolTroisième outil
Office Plant Care
Journal d'arrosage sensible à la météo et aux saisons — petite application live sur l'open core, lecture publique. Un outil, une décision — même principe que ce que je construis pour tout problème qui vaut le coup.
Démo live · lecture publique ; écriture pour l'équipe seulement.
View the appQuatrième outil
Plant Sandbox
Plante virtuelle sans conséquences. Arrose, ajuste la lumière, sur-arrose, observe la reprise — tout état est éphémère. Construit pour illustrer le principe sandbox : un mauvais clic ne coûte rien.
Public · sans auth · remise à zéro au rechargement — espace d'exploration sans risque.
Try the toolComment participer
Trois façons de participer au code ouvert.
Tout est Apache-2.0. Choisis le niveau d'implication qui te convient.
- Premier01
Community
Lance-le toi-même — clone le dépôt, fournis tes propres clés et ton domaine. Le code et la doc, c'est tout.
- Ensuite02
Devlog
Suis les builds au fil du taf — décisions, impasses, ce qui a été livré. Abonne-toi et prends les patterns à ton rythme.
- Pour finir03
Direct
Écris-moi si tu veux parler d'une intégration ou d'un problème précis. Pas de retainer — juste une conversation directe.
08 — Contact
Dis bonjour.
Si tu travailles sur des sujets proches — IA en production, évaluation de LLM, l'AI Act dans une vraie organisation — dis-moi ce que tu fais. Je réponds.
Je mène des recherches sur les défis d'intégration IA dans les équipes industrielles pour mon doctorat — dis-le ci-dessous et je prioriserai ma réponse.hello@apuna.dev
Réponse habituelle sous un jour ouvré