Un produit dont l'IA est le moteur, pas le vernis.

En le concevant d'avance : sur les actions réversibles, l'IA agit ; sur ce qui engage, elle propose et un humain valide. Chaque décision est tracée. Un produit IA sérieux n'est pas un produit qui ne se trompe jamais — c'est un produit dont les erreurs sont bornées et visibles.

Celui qui convient à votre cas — le choix est documenté avec ses raisons (précision, coût, hébergement des données), et l'architecture permet d'en changer sans reconstruire le produit.

Non — c'est un critère de sélection des fournisseurs : contrat de traitement des données, option sans conservation des requêtes, et le circuit exact écrit dans votre documentation. Vos documents servent à répondre à VOS demandes, pas à améliorer le modèle de quelqu'un d'autre.

Moins qu'on ne le croit : quelques centaines de documents ou de cas réels suffisent pour construire et mesurer un premier périmètre. Ce qui compte est la qualité — des documents à jour et représentatifs battent un gros stock contradictoire. Le tri fait partie du chantier.

L'architecture sépare votre produit du modèle : en changer est une opération de réglage, pas une reconstruction. Et la consommation étant plafonnée par contrat, une hausse de tarif déclenche une alerte et une décision — jamais une facture subie.

Avant la mise en service : un jeu d'épreuve construit depuis VOS cas réels (documents, demandes, exceptions), la précision mesurée dessus, échecs comptés, et le seuil d'acceptation écrit avec vous. Après : le journal permet des revues régulières — on rejoue les cas qui ont surpris, on corrige les règles, on re-mesure. La précision d'un produit IA n'est pas un chiffre de plaquette, c'est une courbe qu'on entretient.

Oui, si on respecte deux règles vérifiées sur le terrain : commencer par la tâche que l'équipe déteste (pas celle qui rapporte le plus au dirigeant), et donner à chacun le pouvoir de corriger l'IA — chaque correction améliore le système et le montre. L'IA vécue comme un stagiaire qu'on forme est adoptée ; l'IA vécue comme un surveillant est sabotée. La conduite du changement est dans le chantier, pas en option.

C'est même la seule bonne façon : un périmètre borné qui prouve (un type de document, un type de demande), la mesure à 30 jours, puis l'extension financée par les gains du premier périmètre. Le socle est construit pour ça — étendre est un ajout, pas une reconstruction. Les projets IA qui commencent gros finissent en comité ; ceux qui commencent juste finissent en production.

Trois choses qu'on peut vérifier : des règles et données propriétaires (le produit sait des choses sur VOTRE métier que le modèle nu ne sait pas), un socle qui fonctionne même sans l'IA, et des garde-fous codés avec journal. Un habillage, c'est une interface sur une API — copiable par quiconque lit la même documentation. Un produit, c'est le système autour : c'est lui que vous achetez, et c'est lui qui vaut quelque chose dans trois ans.

Oui — les modèles actuels sont nativement multilingues, et le surcoût est surtout dans les épreuves : chaque langue activée est testée sur de vrais cas, pas déclarée sur la plaquette. Pour une PME française qui sert des clients internationaux, c'est souvent le gain caché du chantier : le même produit répond correctement en anglais ou en espagnol sans embaucher.

La question se règle par l'architecture avant de se régler par le contrat : sur tout ce qui engage (montants, engagements, envois externes), l'IA propose et un humain identifié valide — la responsabilité suit la validation, comme pour n'importe quel outil. Le journal fournit la preuve de qui a validé quoi. Et le contrat écrit précise les rôles noir sur blanc, au lieu de laisser la question au premier incident.

Quand l'IA converse directement avec eux, oui — transparence obligatoire et, honnêtement, contre-productive à esquiver. Quand elle travaille en coulisse (tri, brouillons validés par un humain, extraction), c'est votre processus interne : la mention dans votre politique de confidentialité suffit, et nous la rédigeons avec vous. La règle simple : celui qui parle à un humain se présente ; celui qui prépare le travail d'un humain est un outil.

Le socle — vos règles, vos données, vos écrans, votre journal — vieillit comme tout bon logiciel : des années, entretenu par le mensuel. La brique modèle, elle, s'améliore sans vous coûter de chantier : l'architecture permet de brancher un modèle plus récent quand il apporte quelque chose de mesurable. En clair, votre produit profite des progrès de l'IA au lieu d'être périmé par eux — c'est toute la différence entre construire un produit et acheter une mode.

Oui, c'est le rôle du mensuel : surveillance, corrections, plafonds de coûts — et une revue régulière du journal pour continuer d'affiner les règles avec vous. Les évolutions plus larges (nouveau type de document, nouveau périmètre) se chiffrent en devis séparé sur le même socle. Et si vous préférez internaliser, tout est documenté pour que votre équipe reprenne la main — c'est votre produit.