Anatomie d'un harnais IA
Pourquoi certains builders livrent en une soirée ce que d'autres cadrent en un trimestre
Introduction
Steve Yegge défend une thèse brutale : l’écart ne se joue plus entre bons et mauvais développeurs, mais entre ceux qui utilisent l’IA comme un assistant dans Cursor et ceux qui apprennent à piloter des agents, puis des ensembles d’agents. Dans cette nouvelle courbe d’adoption, l’écart de productivité peut devenir immense.
Mais quand on entend ce type de thèse, la mauvaise explication vient toujours en premier : modèles plus intelligents, Claude Opus, davantage de paramètres. C’est faux, ou du moins secondaire. Les développeurs 2x voire 20x plus productifs utilisent souvent les mêmes familles de modèles. La différence se joue moins dans le modèle lui-même que dans l’architecture qui l’enveloppe, le contexte qu’on lui sert, les outils qu’on lui ouvre, et la manière dont on sépare le jugement de l’exécution.
Garry Tan, président de Y Combinator, a nommé cette architecture le harnais. Une fine couche logicielle qui entoure le modèle, charge le bon contexte au bon moment, et sépare rigoureusement ce qui relève du jugement de ce qui relève de l’exécution.
J’ai passé les derniers mois à construire le mien. Je l’ai appliqué à mes propres produits avant de le vendre à qui que ce soit, par principe : on ne vend pas une doctrine qu’on n’a pas appliquée à soi-même. Mardi dernier, j’ai écrit un post LinkedIn sur cette thèse. Mercredi en début de soirée, je me suis posé la question honnête : si je crois vraiment ce que je viens d’écrire, puis-je le prouver sur moi-même avant la fin de la journée ?
Quelques heures plus tard, Cognitia tournait. Un tableau de bord de veille IA qui tient la carte des débats stratégiques en temps réel sur un secteur donné. Un produit en production, déployé, accessible.
Un MVP, évidemment. Loin d’être parfait. Et c’est justement là l’intérêt. Un cabinet de veille stratégique met quatre mois à livrer son rapport, parfait le jour de la remise, obsolète trois semaines plus tard. Je me suis inspiré des meilleurs builders pour créer un MVP en une soirée, que je fais vivre ensuite au rythme des retours des premiers utilisateurs. Le produit s’améliore chaque semaine, pas dans quatre mois.
Cognitia n’est pas parti d’une page blanche. Il a été extrait d’un harnais que j’avais déjà construit, testé et déployé pour un acteur du M&A qui avait besoin de suivre ses dossiers et ses signaux concurrentiels. Même moteur, mêmes skills, mêmes résolveurs. Seules changent les sources et le vocabulaire métier.
Cet article décompose ce harnais en cinq concepts, plus un sixième exclusif pour le lecteur web : la méthode de construction étape par étape. Ce n’est pas une théorie. C’est le compte-rendu d’un opérateur qui a payé, en nuits blanches et en infrastructure, chacun des principes qui suivent.
Volet 1 : Le harnais comme tour de contrôle
On vous a vendu que l’IA, c’était le modèle. Ce n’est pas vrai.
Le modèle, c’est le pilote. Brillant, rapide, capable de prendre mille décisions par seconde. Mais un pilote sans tour de contrôle s’écrase. Il ignore quelle piste est libre, quelle météo l’attend, quel avion arrive en face, quelle procédure s’applique à son vol précis.
Le harnais, c’est la tour de contrôle.
Il n’est pas plus intelligent que le pilote, il est simplement structuré autrement. Il voit ce que le pilote ne voit pas. Il charge la bonne information au bon moment. Il empêche les collisions entre ce que le modèle juge et ce que le code exécute. Surtout, il oriente le pilote vers la bonne procédure au bon moment, au lieu de lui demander de tout réinventer à chaque décollage.
Concrètement, un harnais accomplit quatre fonctions, pas davantage.
Il tourne le modèle en boucle. Au lieu d’une seule requête suivie d’une seule réponse, le harnais permet au modèle d’itérer. Il propose une action, observe le résultat, décide de la suivante. Cette boucle transforme un chatbot en agent.
Il lit et écrit les fichiers du projet. Le harnais donne au modèle la capacité d’explorer une base de code, de consulter une documentation, de modifier un fichier, sans qu’un humain verrouille chaque opération. C’est ce qui sépare un assistant qui répond à des questions d’un collaborateur qui exécute des tâches.
Il gère le contexte, et c’est sans doute sa fonction la plus critique. La fenêtre de contexte d’un modèle est finie. Si on la remplit de bruit, le modèle se noie. Le harnais devient le gestionnaire qui décide quoi charger, quoi oublier, quoi résumer, à chaque étape.
Il fait respecter la sécurité. Le harnais impose des garde-fous. Certaines opérations sont autorisées, d’autres non. Il évite que le modèle, dans son enthousiasme, ne supprime un fichier critique ou n’envoie une requête API destructive.
C’est tout. Un bon harnais ne fait rien de plus. L’anti-pattern le plus répandu en 2026, c’est le harnais obèse : quarante outils définis dont la moitié se recouvrent, des wrappers MCP qui prennent quinze secondes pour un clic de souris, des abstractions qui consomment la moitié de la fenêtre de contexte avant même que le modèle ait commencé à travailler.
Un harnais gras ralentit tout ce qu’il touche. Un harnais fin fait confiance aux skills pour contenir l’intelligence et se concentre sur sa seule mission : orchestrer. Tan appelle cette discipline “thin harness, fat skills”, et c’est l’axe de lecture à garder en tête pour la suite de cet article.
Quand j’ai construit Cognitia en soirée, mon harnais faisait environ deux cents lignes de code. Deux cents lignes qui orchestrent des dizaines de skills, lisent des sources RSS, interrogent des bases documentaires et produisent une war-room doctrinale. Le pilote, c’est Claude. La tour de contrôle, c’est mon harnais. Les skills, c’est ce qu’il y a dans les manuels de procédure rangés dans la tour.
Volet 2 : Les skills comme méthodes paramétrables
J’ai un fichier markdown de quatre cents lignes qui s’appelle /investigate. Il ne fait rien tout seul.
Quand je lui passe en paramètre “safety scientist” et 2,1 millions d’emails juridiques, il devient un analyste médical qui cherche un whistleblower étouffé dans une affaire pharmaceutique. Quand je lui passe “shell company” et des documents FEC, il devient un enquêteur forensique qui trace des donations politiques coordonnées à travers une cascade de sociétés écrans.
Même fichier. Mêmes sept étapes de raisonnement. Des capacités radicalement différentes.
Voilà ce qu’est une skill.
Une skill n’est pas un prompt. Ce n’est pas un système d’instructions statique qu’on colle en tête d’une conversation. Une skill est une méthode, au sens de la programmation orientée objet : un bloc de procédure nommé, qu’on invoque avec des paramètres, et qui produit un résultat structuré.
La différence est fondamentale. Un prompt décrit ce qu’on veut. Une skill décrit comment on procède. Le prompt change à chaque utilisation. La skill ne change jamais. Elle est appelée, elle s’exécute, elle rend la main.
Et voici le point que la plupart des gens ne comprennent pas : dans un grand nombre de cas, le langage le plus efficace pour coder une skill n’est ni Python ni du JSON structuré, mais du markdown en langage naturel, lu par le modèle comme runtime.
L’intuition choque au premier abord. Comment un fichier markdown pourrait-il être du code ? La réponse tient à la nature même des LLM. Un modèle lit le texte comme un processeur lit du bytecode, avec toutes les limites de cette analogie. Si le texte décrit une procédure de manière suffisamment précise, le modèle peut exécuter cette procédure avec une grande fidélité. Le markdown devient alors exécutable non parce qu’il est compilé, mais parce qu’il est interprété par un runtime intelligent, probabiliste, et donc jamais parfaitement fiable.
Dans Cognitia, j’ai une skill qui s’appelle /detect-contradictions. Elle prend deux paramètres : un territoire doctrinaire, par exemple “architecture des agents IA”, et une période, par exemple “les quatre-vingt-dix derniers jours”. Elle exécute cinq étapes. Identifier les auteurs influents sur ce territoire pendant cette période. Extraire les thèses principales de chaque auteur. Croiser les thèses par paires pour détecter les oppositions frontales. Remonter aux citations précises pour chaque opposition. Générer un brief qui nomme chaque contradiction, chaque auteur, chaque citation.
La même skill, appliquée au M&A, devient un détecteur de désaccords entre banquiers d’affaires sur la valorisation d’une industrie. Mêmes cinq étapes. Même fichier. Paramètres différents, verticale différente.
Voici l’asymétrie temporelle que les skills peuvent créer. Quand une nouvelle génération de modèle sort, je n’ai souvent besoin de retoucher qu’à la marge mes skills markdown. Elles peuvent devenir meilleures presque automatiquement, parce que le jugement qui s’exécute à l’intérieur des étapes devient plus fin. Pendant ce temps, ceux qui ont figé trop tôt leur logique métier dans du code impératif doivent parfois réouvrir des pans entiers de leur système pour retrouver ce gain.
Les skills sont, à mes yeux, l’un des rares actifs IA qui composent vraiment avec le temps. C’est la raison pour laquelle un builder qui codifie sa méthode peut accumuler des rendements, pendant que celui qui prompte à la main repart plus souvent de zéro.
Volet 3 : Les résolveurs comme table de routage
Quand j’ai mesuré mon CLAUDE.md la première fois, il faisait 2358 lignes.
J’y avais entassé mes conventions, mes patterns, les leçons accumulées pendant des mois de build sur Abraij et sur le harnais M&A. Le modèle lisait ce fichier en entier à chaque requête. Son attention se dégradait. Il oubliait le début en lisant la fin. Il confondait parfois un pattern d’une verticale avec celui d’une autre.
J’ai coupé. Il en reste environ deux cents lignes.
Ces deux cents lignes ne contiennent plus de connaissances. Elles contiennent des pointeurs. Quand telle tâche se présente, charge tel document. Quand telle question est posée, consulte telle ressource. Quand tel pattern apparaît, ouvre telle skill.
Un résolveur, donc.
Le résolveur est la table de routage du contexte. Il n’est pas lui-même intelligent. Il n’exécute pas de logique métier. Il se contente de dire au harnais quelle information charger, au moment précis où cette information devient pertinente.
L’analogie la plus juste est celle d’une bibliothèque. Personne ne lit la bibliothèque entière avant d’écrire un essai. On consulte d’abord le sommaire, puis on ouvre le bon livre à la bonne page. Sans sommaire, la bibliothèque est inutilisable. Sans résolveur, un harnais qui connaît plusieurs milliers de lignes de doctrine est aussi inefficace qu’un chercheur qui tenterait de tout lire en même temps.
Dans Cognitia, voici ce qui se passe quand un utilisateur demande une cartographie des positions sur l’architecture des agents IA. Le harnais reçoit la requête. Le résolveur identifie le territoire, “architecture des agents”. Il charge uniquement les sources indexées sur ce territoire : les 80 articles de Garry Tan, Paul Graham, Foundation Capital, Simon Willison et des chercheurs d’Anthropic les plus récents sur le sujet. Il ignore tout le reste du corpus, articles financiers, articles médicaux, papiers académiques non pertinents. La skill /detect-contradictions s’exécute ensuite sur ce contexte propre.
Résultat : le modèle travaille sur 80 sources ciblées au lieu de 3000. Sa fenêtre de contexte reste nette. Sa décision reste précise. Son temps de réponse reste rapide.
Sans résolveur, Cognitia serait inutilisable dans un mois. Avec lui, le corpus peut croître indéfiniment sans dégrader la qualité des briefs produits.
La différence entre un junior qui panique devant une bibliothèque et un senior qui sait exactement quel livre ouvrir, c’est exactement la différence entre un harnais sans résolveur et un harnais avec résolveur. La connaissance n’est pas un problème de quantité. C’est un problème de routage.
Volet 4 : Latent contre déterministe
Un LLM peut placer huit personnes autour d’une table de dîner en tenant compte de leurs personnalités, de leurs affinités, des sujets à éviter, des conversations à provoquer.
Demandez-lui d’en placer huit cents autour de cent tables avec des contraintes croisées. Il hallucinera un plan qui semble plausible. Il sera faux.
C’est ici que la plupart des projets IA en production meurent. Non pas parce que le modèle est mauvais, mais parce que l’architecte a mis le mauvais travail du mauvais côté d’une ligne qu’il n’a pas pris le temps de tracer.
La ligne sépare deux espaces. L’espace latent, où l’intelligence vit. Le modèle lit, interprète, décide, synthétise. C’est le territoire du jugement. L’espace déterministe, où la confiance vit. Même entrée, même sortie, à chaque fois. C’est le territoire de l’exécution pure.
Chaque étape d’un système IA appartient à l’un ou à l’autre. Les confondre tue la performance.
Parmi les tâches latentes : détecter une contradiction entre deux auteurs, synthétiser un brief clinique, décider si un patient est suivi ou à orienter, placer huit invités autour d’une table, classifier l’intention d’un message. Ces tâches demandent toutes du jugement, tolèrent une marge de variabilité, et bénéficient d’un modèle plus puissant.
Parmi les tâches déterministes : compter le nombre de publications d’un auteur sur une période, calculer un total ARR, optimiser un placement de huit cents personnes sur cent tables avec douze contraintes, chercher un mot exact dans une base documentaire. Aucune ne bénéficie de la créativité d’un modèle. Toutes exigent une exactitude absolue. Toutes doivent être déléguées à du code classique.
Dans Cognitia, cette séparation est brutale et systématique.
La détection de contradictions entre auteurs est latente. Le modèle lit, compare, juge.
L’agrégation du nombre d’articles publiés par auteur et par mois est déterministe. Une requête SQL, rien d’autre.
L’extraction des citations qui soutiennent une thèse est latente. Le modèle comprend la rhétorique.
Le tri chronologique de ces citations est déterministe. Un ORDER BY date.
La génération d’un brief synthétique en français est latente. Jugement stylistique et argumentatif.
La numérotation des sections du brief et l’insertion des métadonnées sont déterministes. Du templating.
Cette séparation est la règle qui sépare les produits IA fonctionnels en production de ceux qui ne sortent jamais de la démo. Un système qui laisse le modèle faire des maths finira par halluciner un chiffre. Un système qui laisse du code figé faire du jugement manquera toutes les nuances qui font la valeur d’un brief.
La plupart des fondateurs IA que j’accompagne en mission commettent la même erreur initiale. Ils mettent le modèle partout, puis s’étonnent que le produit hallucine. La réparation n’est jamais “un meilleur prompt”. Elle consiste toujours à tracer la ligne et à déplacer chaque étape du bon côté.
Volet 5 : La diarisation comme briefing d’analyste
Aucune requête SQL, à elle seule, ne produit un brief d’analyste. Aucun pipeline RAG, pris isolément, ne suffit généralement à produire un brief d’analyste de haut niveau. Aucun embedding, aucune recherche sémantique, aucune base vectorielle ne remplace à eux seuls le travail de synthèse, de hiérarchisation et de jugement.
Le modèle doit lire réellement, tenir les contradictions en tête, remarquer ce qui a changé d’un document à l’autre, noter ce qui n’a pas été dit mais aurait dû l’être, et écrire une synthèse structurée. C’est la différence entre consulter une base de données et recevoir le rapport d’un collègue qui a passé sa journée sur le dossier. Le retrieval prépare le terrain ; il ne remplace pas, dans ce type de cas, l’étape latente de synthèse.
C’est ce que Tan appelle la diarisation.
Le terme vient du traitement du signal. Diariser une conversation, c’est attribuer chaque parole à chaque interlocuteur. Tan l’emprunte pour désigner une étape plus large : la transformation d’un corpus brut en un document de jugement structuré, produit par le modèle dans l’espace latent, et qui devient ensuite un objet réutilisable dans le système.
Dans Cognitia, la diarisation produit pour chaque auteur influent un brief d’une page qui contient cinq sections. Ce que l’auteur dit, avec ses thèses principales textuellement citées. Ce que l’auteur fait, avec ses actions documentées, ses investissements, ses prises de position publiques. Les écarts entre les deux, là où il dit une chose et agit autrement. Ses contradictions temporelles, ce qu’il défendait il y a un an et qu’il contredit aujourd’hui. Sa position dans le débat, avec ses alliés, ses opposants, la ligne qu’il occupe.
Cette page n’existe nulle part dans ma base de données. Elle n’existe que parce qu’un modèle a lu, tenu en tête et écrit. Elle est régénérée périodiquement, à mesure que de nouveaux articles sont ingérés, pour rester vivante.
Dans Abraij, la diarisation produit pour chaque patient un brief clinique dont la structure diffère mais dont la mécanique est identique. Motif de consultation actuel. Historique des présentations sur les trois derniers mois. Contradictions dans le récit du patient, entre ce qu’il dit aujourd’hui et ce qu’il disait il y a six semaines. Signaux non verbaux rapportés par le thérapeute dans les observations. Points de vigilance clinique émergents.
Même mécanique, deux verticales, un seul harnais. Deux skills de diarisation, deux résolveurs spécialisés.
La diarisation est, dans mon expérience, l’étape qui commence à transformer un produit IA qui répond à des questions en produit IA qui travaille pour vous pendant que vous dormez. Elle est coûteuse en tokens. Elle est lente à exécuter. Elle n’est pas toujours nécessaire, mais dès qu’un produit doit condenser un corpus mouvant en objets de jugement réutilisables, je n’ai pas trouvé de substitut plus léger qui tienne durablement la route.
Mon pari est que la plupart des produits IA qui garderont une valeur durable en 2027 auront besoin d’une étape de ce genre, même si elle ne s’appelle pas toujours diarisation. Les autres risquent de rester des interfaces sophistiquées à des bases de données, et donc d’être plus facilement commoditisées par les suites intégrées des grands éditeurs.
Volet 6 : Construction d’un harnais étape par étape
Cette section n’existe que pour le lecteur web. Elle ne figurera pas dans les posts LinkedIn de la série. Si vous êtes arrivé ici, vous avez franchi le filtre du trajet LinkedIn vers acadewie.com, et vous méritez la méthode concrète.
Construire un harnais n’est pas un exercice théorique. Qui attend d’avoir tout compris avant de commencer ne commence jamais. Voici la méthode que j’applique à chaque nouveau projet, dans l’ordre exact.
Étape 1 : Identifier trois cas d’usage réels, pas cinquante
La tentation du fondateur IA débutant, c’est de lister cinquante fonctionnalités possibles avant d’en coder une seule. C’est l’erreur qui fait échouer les produits IA dans l’abstraction stérile du “framework qui peut tout faire et qui ne fait rien de bien”.
Je commence toujours par identifier trois cas d’usage concrets, chiffrés, observables. Pour Cognitia, ces trois cas étaient les suivants. Générer un brief sur Garry Tan et sa position actuelle sur l’architecture des agents. Détecter les contradictions entre les thèses de Foundation Capital et celles de Jamin Ball sur les systems of record. Cartographier les dix voix les plus influentes sur le context engineering et leurs positions relatives.
Trois cas. Ni dix, ni cent. Trois.
Étape 2 : Résoudre chaque cas à la main, sans automatisation
Je résous les trois cas manuellement, en utilisant Claude comme assistant conversationnel classique. Pas de skill, pas de harnais, pas d’architecture. Simplement moi et un modèle, pendant quelques heures.
Cette étape est contre-intuitive mais essentielle. En résolvant à la main, je découvre quelles sources sont réellement utiles et lesquelles ne sont que du bruit. Quelles étapes de raisonnement sont indispensables. Où le modèle hallucine et où il est précis. Quelles instructions font la différence entre un résultat médiocre et un résultat utilisable.
On ne peut pas codifier une procédure qu’on n’a jamais exécutée. Les fondateurs qui tentent d’architecturer avant d’avoir résolu à la main produisent toujours des systèmes qui ne fonctionnent pas en conditions réelles.
Étape 3 : Extraire la procédure commune en une skill
Une fois les trois cas résolus, je remarque ce qui leur est commun. Pour Cognitia, les trois cas partageaient la même structure en cinq étapes : identifier les auteurs, extraire les thèses, croiser pour détecter les oppositions, remonter aux citations, générer le brief.
Je codifie cette structure dans une skill markdown. Je la paramètre avec les seules variables qui changent entre les trois cas : le territoire, la période, le type d’output.
La skill initiale fait cent cinquante à deux cent cinquante lignes. Pas davantage. Les skills obèses sont des skills insuffisamment éprouvées.
Étape 4 : Tester la skill sur trois cas supplémentaires, non anticipés
Je prends trois nouveaux cas que je n’avais pas en tête quand j’ai conçu la skill. Pour Cognitia, ces cas étaient les suivants. Cartographier les positions sur la régulation de l’IA en Europe. Détecter les voix émergentes sur l’open source IA en 2026. Analyser les désaccords entre les chercheurs d’Anthropic et ceux de DeepMind sur l’alignement.
Si la skill fonctionne sur ces trois nouveaux cas sans modification, elle est généralisée. Si elle échoue sur un ou plusieurs d’entre eux, je ne la patche pas au coup par coup. Je relis le compte-rendu d’échec, j’identifie le pattern manquant et je réécris la skill proprement. Une skill rapiécée accumule les bugs. Une skill régulièrement réécrite reste propre.
Étape 5 : Construire le résolveur quand trois skills au moins existent
Tant que je n’ai qu’une seule skill, je n’ai pas besoin de résolveur. La skill s’appelle elle-même. Le résolveur devient pertinent quand je dispose d’au moins trois skills et que je dois décider laquelle invoquer selon le contexte.
Le résolveur initial est ridiculement simple : une liste de déclencheurs mots-clés associés à des skills. Il évolue vers un système plus sophistiqué, fait de matching sémantique, de priorités, de fallbacks, seulement quand la simplicité montre ses limites.
Règle stricte : ne jamais sur-architecturer un résolveur avant d’en avoir besoin. Un résolveur trop complexe au début est plus coûteux à déboguer qu’un ajout ciblé de complexité plus tard.
Étape 6 : Tracer la ligne latent/déterministe à froid
À ce stade, j’ai un système qui fonctionne. Mais il consomme trop de tokens. Il est lent. Il hallucine parfois.
Je prends une après-midi pour auditer chaque étape et la classer, latente ou déterministe. Je suis impitoyable. Tout ce qui peut être déterministe doit l’être. Je déplace chaque étape du bon côté de la ligne.
Dans Cognitia, cet audit a permis de diviser par trois le coût en tokens et par deux le temps de réponse. Sans changer de modèle. En déplaçant des étapes.
Étape 7 : Ajouter la diarisation en dernier
La diarisation est coûteuse. Je ne l’ajoute qu’à la fin, quand le reste du système est stable. Elle prend typiquement la forme d’un cron nocturne qui tourne pendant que je dors et qui régénère les briefs structurés avec les nouvelles données de la journée.
C’est la dernière étape, pas la première. Les fondateurs qui commencent par la diarisation se perdent dans la complexité avant d’avoir stabilisé leurs skills.
Le résultat composé
Une fois ces sept étapes traversées, le harnais existe. Il est extractible. Je peux le réutiliser pour construire une nouvelle verticale en changeant les sources, les skills et les résolveurs. C’est exactement ce que j’ai fait pour Cognitia en une soirée. J’ai pris le harnais affiné sur Abraij et sur l’outil M&A précédent, j’ai changé les sources en remplaçant les consultations médicales par des articles de presse IA, j’ai adapté deux skills, et j’ai lancé.
Le harnais est un actif qui compose. Chaque nouvelle verticale enrichit les skills et les résolveurs qui serviront à toutes les suivantes. C’est pourquoi la vingt-cinquième verticale se construit en quelques heures, alors que la première a demandé des mois.
Conclusion
Mon pari est qu’en 2028, les cabinets de conseil qui n’auront pas construit leur propre harnais auront quitté le centre de gravité de la carte IA sérieuse.
Non pas seulement parce que les modèles seront devenus plus intelligents, mais parce que la différence entre un cabinet qui vend principalement de la main-d’œuvre et un cabinet qui vend un harnais composé pendant cinq ans est une différence de nature, pas seulement de degré. Le premier facture son temps. Le second facture sa capacité de composition. Les clients, une fois cette différence rendue visible, arbitreront autrement.
La plupart des cabinets pensent qu’un harnais est un problème d’ingénierie pure, à déléguer au CTO. C’est une erreur. Un harnais est un objet doctrinal avant d’être un objet technique. Il encode la manière de penser d’un praticien senior. Sans cette doctrine préalable, le harnais n’est qu’une coquille.
C’est pourquoi, chez Acadewie, je construis pour chaque mission le harnais qui incarne la doctrine métier du client. Pas un framework générique. Un harnais taillé sur mesure, qui encode les décisions réelles des meilleurs opérateurs de l’équipe, et qui leur reste après mon départ.
La question que je pose aux opérateurs arrivés jusqu’ici : qu’est-ce que vos meilleurs collaborateurs décident tous les jours, et que votre SI n’a jamais stocké ?
C’est le point de départ de votre harnais. Tout le reste est de l’ingénierie.
Mounir, consultant IA freelance à travers Acadewie. Il a construit Cognitia en une soirée, et Abraij, scribe ambiant médical en environnement HDS, pendant six mois en solo. Pour discuter d’un harnais pour votre équipe : hello@acadewie.com
Consultant senior IA freelance. Construit Cognitia et Abraij, pour prouver par ses propres mains ce que les textes défendent. Intervient auprès de grands groupes à la vitesse d'une startup, à travers Acadewie.