Construire avec l'IA en solo : ce que cela vous apprend vraiment

Trois produits d’IA en dix-huit mois, sans équipe, sans cofondateur, sans financement extérieur. Ce n’est pas une fanfaronnade, c’est la condition dans laquelle j’ai appris la chose dont traite réellement ce texte, parce que construire seul supprime tous les endroits où se cacher de ce qu’un outil sait et ne sait pas faire, et de ce qu’il coûte vraiment pour continuer à tourner.

GuruCat est venu en premier, une application mobile faisant de la reconnaissance d’images sur des photos de chats pour générer un contenu de « guidance psychique » — construite, publiée sur l’App Store, puis retirée quand l’économie unitaire B2C n’a pas tenu. Posterprints.art a suivi : une opération e-commerce en IA générative qui a dépassé 600 références réparties en 29 collections, portée par Pinterest, toujours en ligne et en vente. Omega Praxis est le projet actuel, une plateforme B2B qui tourne sur le même muscle du constructeur solo, visant un problème plus difficile.

Ce que vous apprenez en construisant ainsi n’est dans aucune certification, parce que les certifications enseignent des outils, et l’outil sur lequel vous vous certifieriez cette année est déjà en partie obsolète au moment où le cours sort. La génération de code est rapide, cette partie du battage est exacte. Les décisions d’architecture restent entièrement à vous ; le modèle générera volontiers une structure qui marche pour la démo et s’effondre à l’échelle, et il n’a aucun avis sur celle qu’il vient de vous remettre. Déboguer du code généré par IA s’est révélé une compétence à part, distincte du débogage de votre propre code, parce que vous lisez une logique que vous n’avez pas écrite et que vous ne pouvez pas entièrement prévoir, produite par quelque chose d’assez sûr de lui pour ne jamais signaler ses propres erreurs.

Le contrôle qualité sur 600 références m’a appris plus sur l’endroit où l’IA générative casse réellement que n’importe quel benchmark que j’aie lu, parce qu’un benchmark vous donne le cas moyen et un catalogue vivant vous montre le mode de défaillance qui apparaît à la référence 340 et nulle part dans les cinquante premières. C’est une tâche étroite, répétitive et bien définie, avec un critère de réussite clair — exactement le profil qu’un petit modèle local traite bien, et exactement le profil que je dirais maintenant à tout constructeur solo d’arrêter de faire passer par un appel d’API généraliste coûteux. L’adéquation à la tâche n’est pas un détail ; rédiger la description produit destinée au client s’accorde mal avec quoi que ce soit que vous feriez tourner sur votre propre machine et appartient au meilleur modèle cloud que vous pouvez vous offrir, tandis que classer et étiqueter 600 références selon une taxonomie fixe s’accorde très bien avec quelque chose de plus petit et moins cher tournant en local. Connaître cette différence sur le bout des doigts, parce que j’étais la seule personne à payer pour l’avoir mal comprise, n’est pas une ligne qu’enseigne une certification.

La discipline de coûts fonctionne de la même manière en solo que pour un dirigeant de PME qui dimensionne une installation locale, sauf que vous sentez chaque euro personnellement, sans budget d’un autre pour absorber l’erreur. Le matériel, le temps d’installation, les heures passées à maintenir un modèle à jour : rien de tout cela n’apparaît sur une facture d’abonnement, cela apparaît dans vos propres soirées. C’est la ligne de maintenance que toute estimation de coût d’IA locale omet jusqu’à ce que quelqu’un pose la question de qui fait réellement les quatre heures par mois de mises à jour et de surveillance, et pour un constructeur solo la réponse honnête est toujours « moi » — ce qui explique exactement pourquoi je choisis désormais le cloud par défaut pour tout ce qui n’est pas à gros volume et assez étroit pour justifier son coût. Le calcul de rentabilité qui a du sens pour une entreprise de trente personnes pesant un serveur dans une pièce du fond ne change rien pour une seule personne ; mes volumes tendent à justifier le basculement uniquement pour la tâche la plus répétitive et la plus fréquente du pipeline, et tout le reste reste sur le modèle généraliste que je n’ai pas à maintenir.

La leçon plus profonde se trouve sous les trois entreprises plutôt que dans l’une d’elles : l’outil change tous les quelques mois, mais le flux de travail — idée, génération, évaluation, itération, livraison — n’a pas changé une seule fois à travers trois produits complètement différents sur trois marchés complètement différents. Ce flux est le véritable actif transférable, et il inclut maintenant une décision que je n’avais pas à prendre explicitement il y a deux ans : pour chaque étape, est-ce que cela tourne sur le modèle généraliste, ou est-ce que cela mérite un outil plus petit, moins cher et plus étroit pour lui seul. Ce flux n’est presque jamais ce qui est enseigné, parce que la plupart des formations organisationnelles à l’IA sont encore construites autour de l’outil du moment — ce qui leur donne une durée de vie mesurée en cycles de mise à jour produit — et autour d’une fausse alternative entre « le cloud » et « votre propre serveur » qui ne survit pas au contact d’un vrai catalogue.

Ce que je voudrais réellement enseigner à une équipe, si je dirigeais ce programme, c’est le flux de travail en dessous, la partie qui survit à la prochaine sortie de modèle, au prochain changement de tarif et au prochain débat local contre cloud qui s’avère n’être ni nouveau ni un débat qu’on gagne une fois pour toutes. Savoir si cela s’enseigne à l’échelle, hors des conditions du solo où la facture de maintenance ne retombe que sur vous, est la question ouverte à laquelle je n’ai toujours pas de réponse complète.