Comment le développement de logiciels pour produits IA fonctionne réellement

La plupart des projets de produits IA échouent avant le premier appel au modèle. Non pas parce que le modèle est mauvais, mais parce que l'équipe traite le modèle comme le produit. Le développement de logiciels pour produits IA n'est pas de l'ingénierie de prompts enrobée dans une UI. C'est un système composé où les pipelines de données, l'application de schémas, les portes d'approbation et le modèle lui-même doivent fonctionner ensemble, et chaque composant doit être correct. Voici comment un engagement fonctionne réellement quand je le prends en charge.

L'appel de cadrage est où l'architecture commence

La première conversation ne porte pas sur le modèle à utiliser. Elle porte sur ce que l'output doit être, et qui en est responsable. Ces deux questions décident de presque tout le reste.

Je demande au fondateur ou au responsable produit de décrire la pire chose qui pourrait se produire si le système retourne une mauvaise réponse. S'ils disent « les utilisateurs seraient ennuyés », l'architecture ressemble à une chose. S'ils disent « un utilisateur réserve la mauvaise route de visa et se fait refuser à la frontière », elle ressemble à quelque chose de complètement différent. Fursa était du deuxième type. Le produit couvre l'admissibilité dans plus de 170 pays de destination. Une réponse confiante mais fausse est pire que pas de réponse du tout. Cette contrainte a façonné chaque couche du système, pas seulement l'étape de récupération.

À la fin du premier appel, je veux savoir : quelles données existent, qui les possède, à quoi ressemble la chaîne d'approbation, et si l'équipe a une tolérance pour la latence en échange de la précision. Le budget et le calendrier viennent après, car ils dépendent de ces réponses.

La première semaine est de la recherche, pas de la construction

Je n'ouvre pas un éditeur de code la première semaine. Je cartographie les sources de données, je trace le parcours utilisateur de bout en bout, et j'écris un court document d'architecture qui nomme les composants et leurs modes de défaillance.

En 2026, la norme de production pour les workflows agentiques est les systèmes composés, pas les chaînes de prompts uniques. Les frameworks comme LangGraph et LlamaIndex Workflows sont construits autour de l'idée que le modèle est un nœud dans un graphe, pas le graphe lui-même. C'est le bon modèle mental. Chaque nœud a un schéma d'entrée défini et un schéma de sortie défini. Si un nœud retourne quelque chose en dehors du schéma, le système ne devine pas. Il s'arrête et escalade.

L'application stricte de schémas n'est pas optionnelle. C'est le mécanisme qui rend le reste du système fiable. J'ai vu des équipes la sauter pour aller plus vite et ensuite passer trois semaines à déboguer des défaillances silencieuses où le modèle a retourné un objet plausible mais structurellement incorrect qui s'est propagé à travers les étapes suivantes avant que quelqu'un ne le remarque.

Le document d'architecture que j'écris la première semaine nomme chaque nœud, chaque limite de schéma, et chaque endroit où un humain doit approuver avant que le système continue.

Les portes d'approbation humaines ne sont pas un contournement pour les mauvais modèles

C'est la chose que je dois expliquer le plus souvent. Les équipes supposent que les portes d'approbation sont une mesure temporaire pendant que le modèle s'améliore. Elles ne le sont pas. C'est une décision de conception sur qui est responsable d'un output.

Sur Job Hunter, le système explore plus de 185 pages de carrière quotidiennement et génère des brouillons de prise de contact. Le modèle est bon à cela. Mais la prise de contact sort sous le nom d'une vraie personne, à un vrai recruteur, avec de vraies conséquences pour la réputation de cette personne. Donc le brouillon va à l'utilisateur avant d'aller ailleurs. Ce n'est pas une limitation. C'est le produit.

La porte d'approbation génère aussi un signal d'entraînement. Chaque fois qu'un utilisateur modifie ou rejette un brouillon, c'est de la donnée sur ce qui est bon pour cet utilisateur. Au fil du temps, le système s'améliore sur la dimension qui compte réellement, l'adéquation pour la personne spécifique qui l'utilise, pas l'adéquation pour un benchmark moyen.

Bien construire la porte d'approbation signifie la penser comme un problème d'UI autant que comme un problème de systèmes. La porte doit montrer à l'utilisateur assez de contexte pour prendre une décision rapide et confiante. Si la porte est lente ou confuse, les utilisateurs approuvent tout, et la porte cesse de fonctionner.

La vérification par rapport aux sources est un problème d'ingénierie

Pour tout produit IA où l'output est une affirmation sur le monde, la récupération doit être traçable. L'utilisateur doit pouvoir voir d'où vient la réponse. Le système doit pouvoir échouer gracieusement quand la source est manquante ou obsolète.

C'est un problème d'ingénierie plus difficile que la plupart des équipes ne l'attendent. Ce n'est pas juste ajouter des citations. Cela signifie que l'étape de récupération doit retourner des métadonnées structurées aux côtés du chunk, l'étape de génération doit être contrainte à ce que la récupération a retourné, et le format de sortie doit faire apparaître la source d'une manière que l'utilisateur lit réellement.

Sur Fursa, chaque résultat d'admissibilité est lié au document source qui le soutient. Si le document source est obsolète, le système signale le résultat plutôt que de le présenter comme actuel. Cela a nécessité de construire une couche de fraîcheur dans le pipeline de données, pas seulement l'étape du modèle. GritGateway avait une exigence similaire sur les données de talents de plus de 25 pays africains, où la qualité des sources varie considérablement selon la région.

Tester un produit IA est différent de tester un logiciel

Les tests unitaires couvrent les limites de schémas. Les tests d'intégration couvrent les chemins de workflow. Mais aucun de ceux-ci ne vous dit si les outputs sont réellement bons.

Je construis un ensemble d'évaluation tôt, avant que le premier modèle ne soit connecté. L'ensemble d'évaluation est une collection d'inputs avec des outputs connus comme bons, convenus avec le client. Certains de ces inputs sont des cas limites. Certains sont adversariels. L'ensemble d'évaluation s'exécute sur chaque déploiement et les résultats vont dans un tableau de bord que le client peut voir.

Cela importe parce que le modèle va changer. L'API sous-jacente va se mettre à jour. L'index de récupération va dériver à mesure que de nouveaux documents sont ajoutés. Sans un ensemble d'évaluation, vous découvrez que le système s'est dégradé quand un utilisateur se plaint. Avec un, vous le découvrez avant que le déploiement ne soit en direct.

L'ensemble d'évaluation rend aussi le processus d'approbation plus rapide. Quand un client demande « est-ce sûr de déployer », je peux lui montrer un nombre, pas un sentiment.

À quoi ressemble l'engagement de votre côté

Vous recevez un document de cadrage après le premier appel. Vous recevez un document d'architecture après la première semaine. Vous recevez un environnement de staging avec un tableau de bord d'évaluation fonctionnant avant que nous discutions de la préparation à la production. Chaque décision qui affecte la responsabilité, la propriété des données, ou la chaîne d'approbation est documentée et approuvée avant d'être construite.

Le MVP Sprint est la bonne forme pour la plupart des engagements de produits IA : scope fixe, huit à douze semaines, un système fonctionnant à la fin. Si vous décidez encore si vous devez construire du tout, l'engagement Technical Due Diligence est le chemin plus rapide. Il vous donne une évaluation honnête de la complexité de la construction et des risques avant que vous ne vous engagiez sur le budget.

Si vous êtes proche de commencer et que vous voulez discuter de l'architecture avant toute autre chose, le formulaire de contact est le moyen le plus rapide de me joindre.