IA 101 - Épisode 2. Bonjour le monde en IA ColdFusion : faire dire quelque chose d’utile au robot

Dans le article précédent, nous avons parlé du vocabulaire de base de l’IA : LLM, invites, jetons, fenêtres de contexte, température, absence d’état, hallucinations, outils, RAG, MCP et garde-fous. C’était la conversation du genre « de quoi s’agit-il exactement? » Maintenant, on passe à la partie amusante. Nous allons faire en sorte que ColdFusion communique avec un modèle d’IA.

Pas construire un assistant complet. Pas brancher des outils. Pas mémoriser les préférences de l’utilisateur. Pas chercher dans des documents. Pas se connecter à un serveur MCP d’entreprise gardé par trois architectes et un processus d’approvisionnement.

Juste ceci :

• Envoyer une invite.
• Obtenir une réponse.
• Afficher la réponse.

C’est la version IA de « Hello World ».

Et comme tous les « Hello World », ça commence simplement. Puis, environ douze minutes plus tard, quelqu’un demande si ça peut se souvenir de l’utilisateur, interroger la base de données, appeler Jira, résumer un PDF, appliquer une politique de sécurité et parler le pirate couramment.

Nous y arriverons. Pour l’instant, nous commençons par la couche utile la plus simple de la pile d’IA de ColdFusion : ChatModel().

Ce que nous bâtissons

Dans cet article, nous allons créer une page ColdFusion de base qui envoie une invite à un grand modèle de langage et affiche la réponse.

Le flux ressemble à ceci :

1. Configurer un modèle de clavardage.
2. Envoyer une invite à l’aide de .chat().
3. Lire la réponse.
4. Afficher le message du modèle.
5. Parler des cas où cette approche fonctionne.
6. Parler des cas où cette approche ne suffit pas.
7. Clarifier la différence entre les réponses non diffusées et diffusées en continu.

Cet article se concentre intentionnellement sur ChatModel().

C’est important parce que ChatModel() est la façon sans état et de bas niveau d’interagir avec un modèle. Il ne se souvient pas des messages précédents. Il ne gère pas les sessions utilisateur. Il n’utilise pas d’outils. Il ne connaît pas magiquement votre schéma de base de données, vos règles d’affaires ou la raison pour laquelle quelqu’un a nommé une table tbl_final_final_v2_backup.

Il accepte une entrée et retourne une sortie. C’est donc un excellent point de départ.

Qu’est-ce que ChatModel()?

ChatModel() crée un objet modèle configuré que ColdFusion peut utiliser pour envoyer des invites à un fournisseur d’IA. À un niveau élevé, c’est le pont le plus simple entre votre code CFML et un LLM.

Vous donnez à ColdFusion une structure de configuration avec des détails comme :

• le fournisseur
• la clé API
• le nom du modèle
• la température
• le nombre maximal de jetons
• le délai d’attente

ColdFusion vous renvoie un objet modèle. Ensuite, vous appelez .chat() avec une simple chaîne de caractères. Le modèle retourne une réponse. C’est la boucle de base.

Il est important de comprendre ce que c’est et ce que ce n’est pas.

ChatModel() est utile pour les requêtes directes et ponctuelles. Ce n’est pas la couche à utiliser lorsque vous avez besoin de messages système structurés, d’une mémoire conversationnelle persistante, d’une orchestration d’outils ou d’un comportement d’assistant propre à chaque utilisateur. Ce sont des sujets que nous aborderons plus tard.

Pour l’instant, considérez ChatModel() comme :

« Voici une invite. Donne-moi une réponse. »

Simple. Clair. Dangereux sans supervision. En gros, comme tous les outils utiles jamais inventés.

Avant de commencer

Vous avez besoin de quelques éléments avant que ce code fonctionne.

1. Vous avez besoin d’une version de ColdFusion qui inclut les services natifs d’IA. Cette série est basée sur Adobe ColdFusion 2025 Update 8.
2. Vous avez besoin du package IA installé si votre installation de ColdFusion l’exige. Selon votre configuration, cela peut être géré via l’Administrateur ColdFusion ou le gestionnaire de packages.
3. Vous avez besoin d’un accès à un fournisseur d’IA. Cela peut signifier une clé API pour un fournisseur infonuagique ou une configuration d’inférence locale comme Ollama.
4. Vous devez stocker les secrets correctement.

Le dernier point mérite son propre petit cours. N’inscrivez pas en dur votre clé API directement dans un fichier .cfm pour ensuite la valider dans le contrôle de source. Ce n’est pas de la « commodité pour développeurs ». C’est un futur rapport d’incident portant une fausse moustache.

Utilisez des variables d’environnement, une configuration chiffrée, un gestionnaire de secrets, les paramètres de l’Administrateur ColdFusion ou un autre mécanisme de configuration sécurisé adapté à votre environnement.

Pour les exemples de cet article, je vais supposer que la clé est déjà disponible sous la forme suivante :application.aiApiKey

Cela ne veut pas dire que c’est le seul bon endroit pour la stocker. Ça sert seulement à garder les exemples lisibles.

Le plus petit exemple utile

Voici un appel IA ColdFusion de base :

<cfscript>
chatModelConfig = {
	provider : "openAI",
	modelName : "gpt-5-nano",
	apiKey : application.aiApiKey,
	temperature : 0.3,
	maxTokens : 500,
	timeout : 30
};

chatModel = ChatModel( chatModelConfig );

response = chatModel.chat( "Explain ColdFusion session scope in one short paragraph." );

writeOutput( encodeForHtml( response.message ) );
</cfscript>

C’est la structure de base. Créez la configuration. Créez le modèle de clavardage. Envoyez une invite. Affichez la réponse. Si tout est configuré correctement, ColdFusion envoie l’invite au fournisseur configuré et reçoit une structure de réponse. Le texte généré est disponible dans response.message.

C’est votre premier « Hello World » d’IA avec ColdFusion.

Personne ne reçoit de certificat, mais vous avez le droit d’hocher la tête avec assurance devant votre écran.

Décomposition de la configuration

Passons en revue la structure de configuration.

chatModelConfig = {
	provider : "openAI",
	modelName : "gpt-5-nano",
	apiKey : application.aiApiKey,
	temperature : 0.3,
	maxTokens : 500,
	timeout : 30
};

provider

Le fournisseur indique à ColdFusion quel fournisseur d’IA vous souhaitez utiliser. Il peut s’agir d’OpenAI, d’Anthropic, de Gemini, de Mistral, d’Azure OpenAI, d’Ollama ou d’un autre fournisseur pris en charge par les services d’IA de ColdFusion.

Les noms des fournisseurs et la disponibilité des modèles peuvent varier; consultez donc la documentation de ColdFusion sur l’IA ainsi que la documentation propre à votre fournisseur lorsque vous configurez cela dans une vraie application.

L’avantage, c’est que votre code CFML n’a pas besoin de se transformer en un énorme fouillis d’appels HTTP spécifiques à chaque fournisseur. Le cadre d’IA de ColdFusion vous donne une interface cohérente, de sorte que le fournisseur peut être traité davantage comme une configuration et moins comme un tatouage architectural permanent.

modelName

Le nom du modèle indique au fournisseur quel modèle utiliser.

Cela compte. Les différents modèles ont des forces, des coûts, des vitesses, des limites et des paramètres pris en charge différents. Certains sont meilleurs pour le raisonnement. Certains sont plus rapides. Certains sont moins chers. Certains prennent en charge des fenêtres de contexte plus grandes. Certains prennent en charge des paramètres que d’autres n’acceptent pas.

Pour un article Hello World, le modèle précis n’est pas le sujet. Le point, c’est que votre application ne devrait pas supposer que chaque modèle se comporte exactement de la même façon. Cette hypothèse finira éventuellement par se glisser dans vos journaux à 2 h du matin, vêtue d’une trace de pile.

apiKey

La clé API authentifie votre application auprès du fournisseur. Encore une fois, ne la codifiez pas en dur dans votre source. Si vous utilisez un fournisseur local comme Ollama, il se peut que vous n’ayez pas besoin d’une clé API. Mais pour les fournisseurs infonuagiques, vous en aurez généralement besoin.

temperature

La température contrôle à quel point la sortie doit être prévisible ou créative. Pour cet exemple, j’ai utilisé :

temperature : 0.3

Cela garde la réponse relativement ciblée. Pour la formation des développeurs, les explications techniques, les classifications, les résumés et les réponses structurées, je commence généralement avec une température plus faible. Je ne veux pas que le modèle fasse preuve d’une créativité débordante lorsqu’il explique la portée de session.

Il y a des moments pour une sortie créative. « Explique la portée de session comme une chanson de marin » en est un. La documentation de production, généralement, non.

maxTokens

maxTokens limite la longueur de la réponse. Cela aide à contrôler le coût, la latence et la verbosité. Sans limite, un modèle peut répondre à une question simple par une dissertation. Parfois, c’est utile. Parfois, l’utilisateur a demandé un paragraphe et a reçu l’édition longue de La Communauté de l’anneau.

timeout

timeout contrôle combien de temps ColdFusion doit attendre la réponse. Les appels à l’IA sont des appels distants, à moins que vous n’utilisiez un modèle local. Les appels distants échouent. Ils se bloquent. Ils expirent. Ils sont parfois limités par le débit. Ils font occasionnellement tout ce que les appels réseau font quand ils sentent que vous faites une démo en direct.

Définissez toujours un délai d’attente. Votre application devrait avoir un plan pour le cas où le modèle ne répond pas assez vite.

Le prompt

Cette ligne envoie le prompt :

response = chatModel.chat( "Explain ColdFusion session scope in one short paragraph." );

L’appel documenté ChatModel.chat() accepte une simple chaîne. Cette chaîne est traitée comme le message de l’utilisateur. Pour des tâches simples, cela suffit.

Exemples :

response = chatModel.chat( "Summarize this text in three bullet points: #articleText#" );

response = chatModel.chat( "Rewrite this announcement to sound friendlier: #announcementText#" );

response = chatModel.chat( "Classify this support request as billing, technical, account, or other: #requestText#" );

La simplicité est agréable, mais elle a aussi ses limites.

Avec ChatModel.chat(), vous n’envoyez pas une conversation structurée avec des messages distincts de système, d’utilisateur et d’assistant. Vous envoyez une simple chaîne. Si vous avez besoin d’invites structurées, de personas, de mémoire ou d’outils, c’est là qu’Agent() entre en jeu.

Pour cet article, une simple chaîne est parfaite. Le robot doit apprendre à ramper avant de pouvoir courir dans votre infrastructure en tenant des ciseaux.

La réponse

Cette ligne affiche la réponse :

writeOutput( encodeForHtml( response.message ) );

La réponse est une structure. Le texte généré se trouve dans response.message. J’utilise ici volontairement encodeForHtml(). La sortie du modèle est du contenu externe. Elle peut être générée par un modèle d’IA au lieu d’être saisie directement par un utilisateur, mais vous devriez quand même la traiter comme une sortie non fiable.

N’affichez pas aveuglément la sortie du modèle dans une page HTML. C’est ainsi qu’on transforme un « assistant IA » en « assistant de cross-site scripting ». Si vous vous attendez à du texte brut, encodez-le. Si vous vous attendez à du HTML, assainissez-le. Si vous vous attendez à du JSON, analysez-le et validez-le. Si vous vous attendez à un nombre, validez qu’il s’agit bel et bien d’un nombre. Le modèle n’est pas votre couche de validation. ColdFusion est tout de même invité à cette réunion.

Une version un peu plus propre

Le premier exemple convient pour une démonstration, mais je préfère généralement encapsuler l’appel dans une petite fonction ou une méthode CFC, afin que la page elle-même n’ait pas à se soucier de la configuration du modèle.

Voici une version simple au niveau de la page :

<cfscript>
public struct function askAi( required string prompt ) {
	var chatModelConfig = {
		provider : "openAI",
		modelName : "gpt-5-nano",
		apiKey : application.aiApiKey,
		temperature : 0.3,
		maxTokens : 500,
		timeout : 30
	};

	var chatModel = ChatModel( chatModelConfig );

	return chatModel.chat( arguments.prompt );
}

response = askAi( "Explain ColdFusion application scope in one short paragraph." );

writeOutput( encodeForHtml( response.message ) );
</cfscript>

C’est encore volontairement simple. Dans une vraie application, je déplacerais probablement cela dans un CFC de service. Cela permet de garder au même endroit la configuration du fournisseur, la gestion des erreurs, la journalisation et les valeurs par défaut. Par exemple :

component {

	public ai_service function init(
		required string apiKey,
		string provider = "openAI",
		string modelName = "gpt-5-nano"
	) {
		variables.apiKey = arguments.apiKey;
		variables.provider = arguments.provider;
		variables.modelName = arguments.modelName;

		return this;
	}

	public struct function ask(
		required string prompt,
		numeric temperature = 0.3,
		numeric maxTokens = 500,
		numeric timeout = 30
	) {
		var chatModelConfig = {
			provider : variables.provider,
			modelName : variables.modelName,
			apiKey : variables.apiKey,
			temperature : arguments.temperature,
			maxTokens : arguments.maxTokens,
			timeout : arguments.timeout
		};

		var chatModel = ChatModel( chatModelConfig );

		return chatModel.chat( arguments.prompt );
	}

}

Ensuite, votre page devient plus simple :

<cfscript>
response = application.aiService.ask(
	prompt = "Explain ColdFusion queryExecute() in one short paragraph."
);

writeOutput( encodeForHtml( response.message ) );
</cfscript>

C’est déjà mieux. Votre configuration IA a un endroit attitré. Votre page est plus propre. Votre futur vous-même sera un peu moins porté à grommeler pendant une revue de code.

Ajouter une gestion d’erreurs de base

Maintenant, soyons un peu plus réalistes. Les appels à l’IA peuvent échouer pour plusieurs raisons :

• clé API invalide
• nom de modèle non pris en charge
• délai d’attente réseau
• panne du fournisseur
• limite de débit
• paramètre incorrect
• problème de quota
• réponse mal formée
• absurdités cosmiques

Nous devrions donc gérer les erreurs.

<cfscript>
try {
	response = application.aiService.ask(
		prompt = "Explain ColdFusion queryExecute() in one short paragraph."
	);

	writeOutput( encodeForHtml( response.message ) );
} catch ( any error ) {
	writeLog(
		file = "ai",
		type = "error",
		text = "AI request failed: #error.message#"
	);

	writeOutput(
		encodeForHtml(
			"Sorry, I could not generate a response right now. Please try again later."
		)
	);
}
</cfscript>

Ce n’est pas sophistiqué, mais c’est bien mieux que d’afficher une exception brute à l’utilisateur. Les utilisateurs n’ont pas besoin de voir les erreurs du fournisseur. Ils n’ont surtout pas besoin de voir quoi que ce soit qui touche à votre configuration, à votre environnement, aux clés, aux noms de modèles, aux noms d’hôte internes ou aux traces de pile. Cette information appartient aux journaux, pas au navigateur.

Un exemple de formulaire simple

Transformons cela en une petite page fonctionnelle. L’utilisateur saisit une invite. ColdFusion l’envoie au modèle. La réponse s’affiche.

<cfparam name="form.prompt" default="">

<cfscript>
result = "";

if ( len( trim( form.prompt ) ) ) {
	try {
		response = application.aiService.ask(
			prompt = trim( form.prompt ),
			temperature = 0.3,
			maxTokens = 700,
			timeout = 30
		);

		result = response.message;
	} catch ( any error ) {
		writeLog(
			file = "ai",
			type = "error",
			text = "AI request failed: #error.message#"
		);

		result = "Sorry, I could not generate a response right now.";
	}
}
</cfscript>

<cfoutput>
<form method="post">
	<label for="prompt">Posez quelque chose au modèle</label>
	<br>

	<textarea
		id="prompt"
		name="prompt"
		rows="6"
		cols="80"
	>#encodeForHtml( form.prompt )#</textarea>

	<br>

	<button type="submit">
		Poser une question à l’IA
	</button>
</form>

<cfif len( result )>
	<h2>Réponse</h2>
	<pre>#encodeForHtml( result )#</pre>
</cfif>
</cfoutput>

Cette interface n’est pas jolie, et franchement, ce n’est pas censé l’être. C’est un simple environnement de test. Vous pouvez utiliser ce genre de page pour tester les invites, les paramètres du modèle, la latence, la qualité des réponses et la gestion des erreurs avant de créer une expérience plus raffinée.

Toute fonctionnalité d’IA devrait commencer par quelque chose de banal et d’observable. Le banal, c’est bien. Le banal signifie que vous pouvez voir ce qui se passe avant que l’équipe UI n’ajoute des dégradés, des animations de chargement et une mascotte nommée Prompty.

Réponses non diffusées en continu

Les exemples ci-dessus ne sont pas diffusés en continu. Cela signifie que le navigateur ne reçoit pas la réponse tant que le modèle n’a pas terminé de générer la réponse complète et que ColdFusion ne l’a pas reçue.

Le déroulement est le suivant :

1. L’utilisateur soumet l’invite.
2. ColdFusion envoie la requête au modèle.
3. Le modèle génère une réponse complète.
4. ColdFusion reçoit la réponse complète.
5. ColdFusion affiche la page.

C’est l’approche la plus simple. C’est aussi la bonne approche pour de nombreuses tâches. Utilisez la non-diffusion en continu lorsque :

• la réponse est courte
• la tâche s’exécute en arrière-plan
• la sortie doit être validée avant l’affichage
• la réponse doit être analysée comme du JSON
• le modèle peut demander des outils
• la réponse doit apparaître d’un seul coup
• l’utilisateur n’a pas besoin d’une expérience de saisie de type clavardage

La non-diffusion en continu est aussi plus facile à consigner, tester, valider, assainir et réessayer. Cela en fait un excellent choix par défaut. Toutes les fonctionnalités d’IA n’ont pas besoin de ressembler à un robot de clavardage qui tape dramatiquement un mot à la fois, comme s’il révélait l’emplacement d’un trésor enfoui. Parfois, une réponse normale suffit.

Réponses diffusées en continu

La diffusion en continu signifie que l’utilisateur voit la réponse au fur et à mesure qu’elle est générée. Au lieu d’attendre la réponse complète, le navigateur reçoit des fragments. (Vous vous souvenez de <cfflush> ?)

Le déroulement ressemble davantage à ceci :

1. L’utilisateur soumet l’invite.
2. ColdFusion lance la requête au modèle.
3. Le fournisseur/modèle commence à générer du texte.
4. Du texte partiel est renvoyé au navigateur.
5. L’interface se met à jour à mesure que les fragments arrivent.
6. La réponse finale est complétée.

La diffusion en continu peut rendre une fonctionnalité d’IA beaucoup plus rapide, parce que l’utilisateur voit des progrès presque immédiatement. C’est particulièrement utile pour :

• interfaces de clavardage
• longues explications
• articles générés
• remue-méninges
• résumés
• expériences d’assistant interactif

Le streaming, c’est surtout une question d’expérience utilisateur. Le modèle peut prendre le même temps total pour terminer, mais l’utilisateur ne reste pas là à fixer un écran vide en se demandant si l’application a planté, si le réseau est tombé ou si le robot fait simplement un peu de drame.

Le streaming n’est pas toujours meilleur

Le streaming a du style, mais il introduit des compromis. Soyez prudent quand vous faites du streaming :

• JSON structuré
• contenu qui doit être validé avant l’affichage
• sortie sensible
• flux de travail basés sur des outils
• flux de travail qui pourraient devoir masquer ou bloquer la réponse finale
• tout contenu partiel susceptible de mêler l’utilisateur

Par exemple, si le modèle génère du JSON que votre application doit analyser, streamer un JSON partiel vers le navigateur n’est pas utile. Un objet JSON à moitié complété, ce n’est pas « interactif ». C’est juste brisé avec assurance.

Si votre application doit exécuter une règle de protection de sortie avant d’afficher la réponse, le streaming devient plus complexe. Vous ne pouvez pas inspecter complètement la réponse finale si vous en avez déjà montré la moitié à l’utilisateur.

Si votre modèle peut demander un appel d’outil, vous ne voudrez peut-être pas streamer le texte tant que vous ne savez pas si le modèle répond directement ou demande à votre application de faire quelque chose.

Le streaming est excellent pour « écris-moi une explication ». Il l’est moins pour « produis des données validées qui orientent le comportement de l’application ».

Une règle pratique

Commencez sans streaming.

Ajoutez le streaming lorsque l’expérience utilisateur en bénéficie réellement.

C’est la réponse plate, donc elle est probablement correcte.

Pour une première fonctionnalité IA, l’absence de streaming vous permet de vous concentrer sur les bases importantes :

• configuration du modèle
• qualité des invites
• gestion des réponses
• gestion des erreurs
• encodage de la sortie
• latence
• coût
• journalisation

Une fois tout cela stabilisé, vous pouvez ajouter le streaming là où c’est approprié. Ne commencez pas par optimiser l’animation de frappe pendant que l’application fuit encore des traces de pile et accepte des invites plus longues qu’un roman victorien.

Une note sur le comportement documenté de ColdFusion

À ce stade de la série, nous restons près du comportement documenté de ChatModel() : configurez un modèle, appelez .chat() avec une chaîne simple et lisez le message retourné. Cela nous donne une base propre.

Si vous utilisez un fournisseur ou un chemin d’API qui prend en charge le véritable streaming token par token, vous pourriez être en mesure de bâtir un point de terminaison de streaming autour de l’interface de streaming de ce fournisseur. Mais il s’agit d’une considération distincte de l’exemple de base ChatModel().chat() montré ici. Autrement dit, ne confondez pas ces deux idées :

• ChatModel().chat() qui retourne une réponse complète.
• Une interface utilisateur en streaming qui affiche le contenu généré de façon incrémentielle.

Elles sont liées, mais elles ne sont pas la même chose. La première est le parcours « Hello World » IA de ColdFusion documenté. La seconde est un modèle d’expérience utilisateur et d’intégration qui dépend des capacités de streaming exposées par la couche que vous utilisez. Nous garderons notre premier exemple simple et fiable.

C’est ainsi qu’on évite de transformer cet article en « Bienvenue dans l’abstraction asynchrone des fournisseurs de streaming et la mise en mémoire tampon du navigateur, veuillez apporter un casque ».

La conception des invites compte immédiatement

Même dans cet exemple simple, le libellé de l’invite compte. Comparez ces deux invites :

Expliquez ColdFusion.

Et :

Expliquez la portée de session de ColdFusion à un développeur web expérimenté qui est nouveau en CFML. Gardez la réponse sous 120 mots et incluez un cas d’utilisation pratique.

La deuxième invite est bien meilleure. Elle donne au modèle :

• le public visé
• le sujet
• la longueur
• le format
• l’attente pratique

Vous n’avez pas besoin d’une ingénierie d’invite élaborée pour chaque tâche. Mais vous devez dire au modèle ce que vous voulez réellement. De mauvaises invites créent de mauvaises réponses. Des invites vagues créent des réponses vagues. Des invites contradictoires créent des réponses bizarres.

Ce n’est pas propre à l’IA. C’est aussi vrai pour les exigences de projet, les résumés de conférence et les textos qui disent « il faut qu’on parle ».

Essayez quelques invites

Voici quelques bonnes invites de départ à tester avec votre nouvelle page.

Expliquez la fonction queryExecute() de ColdFusion à un développeur venant de PHP. Gardez la réponse sous 150 mots.

Résumez le texte suivant en trois puces :
[coller le texte ici]

Réécrivez ce message pour qu’il sonne professionnel, mais pas corporatif :
[coller le message ici]

Classez cette demande de soutien comme facturation, technique, compte ou autre. Retournez seulement la catégorie :
[coller la demande ici]

Expliquez pourquoi le fait de stocker les clés API directement dans le code source est dangereux. Utilisez un court paragraphe.

Ce sont de bons exemples parce qu’ils sont délimités. Ils disent au modèle quoi faire. Ils ne demandent pas au modèle de connaître votre base de données. Ils ne demandent pas de mémoire. Ils ne demandent pas d’outils. Ils ne demandent pas de RAG. Ils sont exactement le genre de choses pour lesquelles ChatModel() est efficace.

Demandez une sortie structurée avec prudence

Tôt ou tard, vous voudrez une sortie structurée. Par exemple :

Classez cette demande de soutien et retournez du JSON avec category, priority et summary.

Cela peut fonctionner, mais ne faites pas aveuglément confiance à la sortie. Si vous demandez du JSON, votre application devrait quand même :

• analyser le JSON
• gérer les erreurs d’analyse
• valider les clés requises
• valider les valeurs permises
• rejeter les structures inattendues
• éviter d’utiliser directement la sortie pour des actions sensibles

Le modèle peut renvoyer du JSON parfait. Il peut aussi renvoyer presque du JSON, ce qui est le genre de JSON le plus agaçant parce qu’il a l’air correct jusqu’à ce que votre parseur lance une chaise.

Si la sortie structurée est importante, validez-la comme n’importe quelle autre entrée externe.

Journalisation

Vous devriez journaliser les requêtes d’IA, mais avec prudence. Voici des éléments utiles à consigner :

• fournisseur
• nom du modèle
• horodatage de la requête
• latence
• réussite/échec
• type d’erreur
• utilisation de jetons, si disponible
• identifiant d’utilisateur ou identifiant de requête
• nom de la fonctionnalité

Faites attention à la journalisation des invites et des réponses complètes. Les invites peuvent contenir des données sensibles de l’utilisateur. Les réponses peuvent contenir des données sensibles générées. Si vous journalisez tout, votre fonctionnalité d’IA pourrait transformer vos journaux en une deuxième base de données, pire que la première.

Une approche raisonnable consiste à consigner suffisamment de métadonnées pour déboguer les problèmes en production tout en évitant le contenu sensible inutile. Pour le développement, une journalisation verbeuse peut être utile. En production, soyez délibéré.

L’expression « on journalise chaque invite pour toujours » devrait faire sursauter au moins une personne en sécurité.

Où ChatModel() se situe

À ce stade, il vaut la peine de répéter la frontière. Utilisez ChatModel() lorsque la tâche est simple et sans état. Bonnes utilisations :

• résumer ce texte
• réécrire ce paragraphe
• classer ce message
• générer une courte description
• expliquer cette erreur
• traduire ce contenu
• rédiger une réponse
• produire une réponse ponctuelle

Mauvaises utilisations :

• se souvenir de cet utilisateur à travers plusieurs messages
• maintenir une conversation
• suivre une persona détaillée
• appeler des fonctions de l’application
• récupérer des enregistrements de base de données propres à l’utilisateur
• répondre à partir de documentation privée
• appliquer des contrôles de politique complexes
• coordonner des flux de travail en plusieurs étapes

Ces mauvaises utilisations ne sont pas impossibles. Elles nécessitent simplement d’autres couches. C’est justement l’objet du reste de cette série d’articles. ChatModel() est la porte d’entrée, pas tout le bâtiment.

Erreurs courantes

Voici les erreurs auxquelles je m’attendrais dans les fonctionnalités d’IA de première génération.

Coder les secrets en dur

Ne mettez pas de clés API dans le code source. Pas dans les fichiers .cfm. Pas dans les CFC. Pas dans JavaScript. Pas dans un commentaire qui dit « temporaire ». Surtout pas dans un commentaire qui dit « temporaire », parce que ça veut dire qu’il nous survivra tous.

Oublier que le modèle est sans état

Un appel ChatModel() ne se souvient pas de l’appel précédent. Si vous avez besoin de mémoire, utilisez la bonne couche. Nous l’aborderons dans le prochain article.

Faire confiance à la sortie

La sortie du modèle n’est pas automatiquement vraie, sécuritaire, valide ou correctement formatée. Validez-la. Encodez-la. Assainissez-la. Révisez-la au besoin.

Utiliser l’IA pour une logique d’affaires déterministe

N’utilisez pas un modèle pour calculer la taxe de vente, déterminer les autorisations, calculer la paie ou décider si un utilisateur peut accéder à un enregistrement. Utilisez du code. Le modèle peut expliquer le résultat. Il ne devrait pas être la source de vérité.

Ne définir aucun délai d’attente

Chaque appel externe a besoin d’un délai d’attente. L’IA n’est pas spéciale. Elle coûte juste plus cher quand elle devient bizarre.

Envoyer trop de contexte

Ne déversez pas tout dans l’invite parce que « plus de contexte, c’est mieux ». Un contexte pertinent, c’est mieux. Un contexte aléatoire, c’est du bruit accompagné d’une facture d’utilisation.

Sauter la gestion des erreurs

Les appels au fournisseur échouent. Écrivez la gestion des erreurs avant que la production ne vous l’enseigne par danse interprétative.

Une meilleure première fonctionnalité

Une bonne première fonctionnalité d’IA dans une application ColdFusion est quelque chose d’utile mais à faible risque. Par exemple :

• résumer une demande d’assistance pour un administrateur
• réécrire une ébauche d’annonce
• suggérer une description de page plus courte
• classer un message dans une file
• expliquer une erreur de validation dans un langage plus convivial
• générer une première version d’un courriel qu’un humain révise

Ce sont de bonnes premières fonctionnalités parce que l’IA aide l’utilisateur sans contrôler directement une logique d’affaires sensible. C’est là que l’IA brille tôt : réduire les frictions, pas remplacer l’application.

Commencez par l’assistance. Gagnez progressivement votre chemin vers l’automatisation.

Ce qui vient ensuite

Nous avons maintenant un appel IA ColdFusion qui fonctionne. C’est utile, mais cela a une limitation flagrante : ça ne se souvient de rien. Si l’utilisateur dit :

My name is David.

Puis demande :

What is my name?

Un appel ChatModel() sans état de base ne le saura pas à moins que votre application renvoie le contexte précédent. Ce n’est pas un bogue. C’est le modèle qui fait exactement ce que cette couche est censée faire.

Dans le prochain article, nous passerons des invites ponctuelles à l’état de conversation. Nous introduirons la mémoire, les préférences de l’utilisateur, les fenêtres de messages, les fenêtres de jetons et l’isolation par utilisateur.

Cette dernière partie est importante. Parce que si votre assistant IA se souvient accidentellement de la conversation d’un utilisateur pendant qu’il parle à un autre utilisateur, vous n’avez pas construit un outil de productivité utile. Vous avez construit un incident de confidentialité avec une animation de frappe sympathique.

Dernière réflexion

Cette première étape est intentionnellement petite. Configurez un modèle. Envoyez une invite. Lisez response.message. Affichez-la en toute sécurité.

C’est suffisant pour commencer. Le vrai travail n’est pas de faire dire quelque chose au modèle. Cette partie est facile. Le vrai travail consiste à décider quel contexte il reçoit, ce qu’il est autorisé à faire, comment votre application valide le résultat et où l’IA améliore réellement l’expérience utilisateur.

ColdFusion nous donne le point d’intégration. L’application a toujours besoin d’architecture, de sécurité, de validation, de journalisation et de bon sens.

En d’autres mots, le robot peut aider… mais ColdFusion est toujours au volant.