IA ou algorithme : choisir le bon outil avant d’intégrer l’intelligence artificielle
Nous rencontrons de plus en plus souvent cette situation : une application doit trier des demandes, faire un choix entre plusieurs réponses possibles, orienter un formulaire vers le bon service, afficher un résultat adapté ou proposer une action à partir des informations saisies. Très vite, une idée s’impose : si l’application doit décider quelque chose, alors il faut probablement intégrer de l’intelligence artificielle. Le réflexe est compréhensible. L’IA est devenue visible, accessible, presque familière, et elle semble répondre naturellement à tout ce qui paraît flou, mouvant ou difficile à prévoir.
Mais avant d’ajouter une couche d’IA dans une application, une autre question mérite d’être posée : quelle part du problème demande réellement de l’intelligence artificielle ? Dans bien des cas, une logique de décision, un algorithme classique, un système de score ou quelques expressions régulières suffisent à produire un résultat fiable, lisible et maîtrisable. L’IA peut alors rester très utile, non pas forcément comme composant embarqué dans l’application finale, mais comme outil d’aide à la conception, aux tests et à l’amélioration du traitement.
Le besoin est-il vraiment flou ?
Lorsqu’une application doit prendre une décision, nous avons parfois l’impression que le problème demande forcément de “l’intelligence”. Pourtant, la difficulté ne vient pas toujours d’un manque de compréhension. Elle peut venir d’un formulaire trop ouvert, d’une règle métier mal définie, d’un trop grand nombre de paramètres ou d’un cas limite que nous n’avons pas encore isolé. Avant de choisir une technologie, il faut donc commencer par regarder ce que l’application doit réellement décider.
Prenons une demande comme : “J’ai une erreur 500 sur mon site WordPress depuis la mise à jour.” À première vue, c’est une phrase libre. Elle pourrait donc sembler difficile à traiter. Mais en la regardant de plus près, plusieurs indices sont très stables : “erreur 500”, “WordPress”, “mise à jour”. L’application n’a pas besoin de comprendre toute la nuance du message pour proposer une première orientation. Elle peut déjà repérer ces indices et classer la demande comme un problème technique ou une maintenance à vérifier.
/*
On peut déjà décrire cette situation sans écrire de véritable algorithme. Il s’agit seulement de nommer le type de donnée, les indices repérés et la décision attendue.
*/
const besoin = {
type: 'demande entrante',
donnees: 'texte libre',
indices: ['erreur 500', 'WordPress', 'mise à jour'],
decision: 'orienter vers une catégorie'
};
const analyse = {
flou: false,
complexe: true,
raison: 'les indices sont reconnaissables, même si la phrase est libre'
};Dans d’autres cas, le besoin n’est même pas exprimé en langage naturel. Une application métier peut devoir organiser un planning, attribuer une salle, réserver un véhicule ou réunir plusieurs professionnels disponibles sur un même créneau. Ici, il n’y a pas forcément de phrase à interpréter. Les données sont déjà structurées : horaires, lieux, durées, disponibilités, priorités, statuts. Le problème vient plutôt du nombre de contraintes à croiser. Une situation peut être complexe sans être floue.
La différence apparaît encore plus clairement si l’on compare deux demandes. “Erreur 500 sur WordPress” fournit des indices faciles à reconnaître. “Je voudrais revoir mon site parce qu’il ne me ressemble plus” demande davantage d’interprétation. Cette seconde phrase peut évoquer une refonte graphique, un accompagnement stratégique, un problème de contenu, une évolution de l’activité ou simplement un besoin de conseil. Ici, les mots ne suffisent plus toujours à décider automatiquement.
Cette grille de lecture permet de replacer chaque besoin au bon niveau, sans lui appliquer immédiatement la solution la plus complexe. Un motif reconnaissable peut souvent être traité par une regex. Une règle connue appelle plutôt un algorithme. Des contraintes métier demandent une modélisation plus précise, parfois une logique d’optimisation. Un contexte ambigu, volumineux ou fortement dépendant de la formulation peut justifier une analyse humaine ou une IA. L’enjeu n’est donc pas de refuser l’IA, mais de ne pas l’utiliser avant d’avoir compris ce que le traitement doit réellement décider.
Ce qu’un algorithme classique sait très bien faire
Avant de chercher une solution complexe, il faut rappeler une chose simple : un algorithme classique sait déjà faire beaucoup de choses. Il peut trier des informations, filtrer des résultats, comparer des valeurs, orienter une demande, calculer un score ou appliquer des règles métier. Ces traitements ne sont pas secondaires. Ils constituent le cœur de nombreuses applications web, qu’il s’agisse d’un formulaire, d’un moteur de recherche interne, d’un espace d’administration, d’un outil de suivi ou d’un planning métier.
Un algorithme devient particulièrement pertinent lorsque les règles sont connues, même si elles sont nombreuses. Si une demande contient certains termes, si une valeur dépasse un seuil, si une date se situe dans une période donnée, si un profil correspond à plusieurs critères, nous pouvons décrire le traitement étape par étape. L’application n’a pas besoin de “comprendre” au sens humain du terme. Elle doit appliquer une logique claire, dans un ordre précis, avec des conditions prévues à l’avance.
/*
Dans une première version très simple, une demande peut être analysée comme une suite d’indices. Chaque indice reconnu ajoute des points à une catégorie. Le résultat n’est pas magique : il dépend des règles que nous avons choisies.
*/
const demande = 'J’ai une erreur 500 sur mon site WordPress depuis la mise à jour.';
const regles = [
{ categorie: 'problème technique', indice: 'erreur 500', poids: 5 },
{ categorie: 'maintenance', indice: 'mise à jour', poids: 2 },
{ categorie: 'maintenance', indice: 'WordPress', poids: 1 }
];
const scores = {};
regles.forEach(function(regle) {
if (demande.includes(regle.indice)) {
scores[regle.categorie] = (scores[regle.categorie] || 0) + regle.poids;
}
});
console.log(scores);
/*
Ce fragment ne prétend pas résoudre tous les cas. Il montre simplement le principe : une décision peut être construite à partir de règles visibles, pondérées et vérifiables.
*/Cette logique ne concerne pas seulement les textes ou les formulaires. Dans une application métier, l’algorithme peut aussi croiser plusieurs contraintes : vérifier si une personne est disponible, si une salle est libre, si un véhicule peut être mobilisé, si un délai est compatible ou si une priorité doit passer avant une autre. Le traitement peut alors éliminer les combinaisons impossibles, classer les solutions restantes et signaler les situations qui demandent un arbitrage humain. Le problème est parfois complexe, mais il reste structurable.
L’un des grands avantages de cette approche est qu’elle reste explicite. Nous pouvons relire la règle, la modifier, la tester, l’expliquer à un client ou à une équipe. Si une demande est orientée vers la mauvaise catégorie, nous pouvons chercher pourquoi : quel mot a été détecté, quel score a été calculé, quel seuil a été franchi. Avec une logique algorithmique bien posée, l’erreur n’est pas forcément agréable, mais elle reste observable.
Ce principe est repris dans la démonstration v1 proposée en complément de l’article Orientation automatique d’une demande utilisateur. Elle montre comment une demande peut être orientée sans API d’IA, à partir d’une normalisation du texte, de règles par mots-clés, d’expressions régulières et d’un score de confiance. La décision reste locale, lisible et directement observable dans le navigateur.
C’est souvent ce qui manque lorsque l’on ajoute trop vite de l’IA dans un traitement simple. On obtient parfois une réponse correcte, mais plus difficile à expliquer, à stabiliser ou à reproduire. Le “bon vieil algorithme” n’est donc pas une solution dépassée. C’est un outil fiable, lisible et maîtrisable, particulièrement adapté aux situations où le besoin peut être décrit sous forme de règles, de conditions, de scores ou de priorités.
Les regex : détecter des motifs sans comprendre le texte
Dans cette logique, les expressions régulières occupent une place particulière. Elles sont parfois perçues comme arides ou difficiles à relire, mais elles rendent de grands services dès qu’il faut reconnaître une forme dans une chaîne de caractères. Une regex ne comprend pas le texte. Elle ne sait pas ce qu’une phrase veut dire. En revanche, elle peut détecter très efficacement un motif identifiable : une adresse e-mail, une URL, un code postal, une référence produit, une extension de fichier, un numéro de commande ou une structure particulière dans une saisie utilisateur.
Cette distinction est essentielle. Lorsque nous utilisons une expression régulière, nous ne demandons pas à l’application d’interpréter une intention. Nous lui demandons de repérer une forme stable. Si un message contient une adresse e-mail, une URL ou une référence du type CMD-2026-1845, il n’est pas nécessaire d’appeler une IA pour les identifier. Une regex bien ciblée peut extraire ces éléments, les vérifier ou déclencher une orientation dans le traitement. Nous avions déjà abordé cette logique dans l’article « Expressions régulières : l’outil discret qui traverse nos projets », où les regex sont présentées comme une manière de repérer une structure stable sous des formes variables.
/*
Dans cet exemple, la regex ne cherche pas à comprendre toute la demande. Elle repère seulement deux formes utiles : une référence de commande et une erreur PHP.
*/
const message = 'Bonjour, ma commande CMD-2026-1845 affiche une erreur PHP Fatal error.';
const referenceCommande = message.match(/\bCMD-\d{4}-\d{4}\b/);
const erreurPhp = message.match(/\b(php\s+(fatal\s+)?error|warning|notice|parse error)\b/i);
console.log(referenceCommande?.[0]); // CMD-2026-1845
console.log(erreurPhp?.[0]); // PHP Fatal error
/*
Ces deux informations peuvent ensuite être transmises à une logique de décision : ouvrir un ticket, orienter vers le support technique ou enrichir un score de catégorie.
*/Les regex peuvent aussi intervenir dans des problèmes plus métier, mais à leur juste place. Dans un outil de planning, de disponibilité ou d’attribution de ressources, elles peuvent aider à reconnaître une date saisie dans un certain format, un code de salle, une référence de véhicule ou un identifiant interne. Mais elles ne décident pas de la meilleure organisation possible. Cette décision relève plutôt d’une logique métier, d’un algorithme de contraintes ou d’un système de priorité. La regex repère une forme ; l’algorithme décide quoi en faire.
Elles sont également utiles pour stabiliser une donnée avant analyse. On peut supprimer des espaces inutiles, repérer des caractères non attendus, contrôler un format ou isoler une information dans une phrase plus longue. Cette étape de nettoyage prépare le terrain pour la suite. Une donnée mieux cadrée devient plus facile à comparer, à classer ou à transmettre à une autre fonction. Dans notre démonstration v1, les regex servent ainsi à repérer des signaux précis, comme une erreur PHP, une adresse e-mail, une mention de CSV ou de JSON, ou encore une demande liée à l’IA.
La démonstration « Orientation automatique d’une demande utilisateur » illustre ce principe dans une interface très simple. Les expressions régulières y complètent les mots-clés pour détecter certains signaux plus précis, sans intégrer d’API d’intelligence artificielle dans l’application finale.
Il faut toutefois rester prudent. Une regex devient fragile lorsqu’on lui demande plus que ce qu’elle sait faire. Elle peut reconnaître P100-200, mais elle ne saura pas, seule, comprendre une phrase comme “je cherche quelque chose de pas trop cher pour commencer”. Elle peut détecter une référence de salle, mais elle ne saura pas choisir le meilleur créneau pour réunir cinq personnes. Les expressions régulières sont puissantes lorsqu’elles repèrent des motifs clairs, elles deviennent limitées lorsque le problème demande une interprétation ou un arbitrage.
Inventer un langage de recherche adapté au besoin
Dans le chapitre précédent, nous avons vu qu’une expression régulière pouvait reconnaître une forme comme P100-200, P>200 ou T|XS|S. Mais ces formes ne sortent pas de nulle part. Elles supposent que nous ayons défini, en amont, une petite convention de saisie. C’est là qu’apparaît une solution intermédiaire intéressante : entre le formulaire classique, composé de champs séparés, et la saisie totalement libre en langage naturel, nous pouvons parfois inventer un pseudo-langage de recherche adapté à l’application.
L’idée n’est pas de créer un vrai langage de programmation, ni de demander à l’utilisateur d’apprendre une syntaxe complexe. Il s’agit plutôt de proposer une écriture courte, prévisible et facile à analyser. Au lieu de saisir une phrase comme “je cherche un article entre 100 et 200 euros en taille XS ou S”, l’utilisateur peut écrire P100-200 T|XS|S. Dans cet exemple, P100-200 indique un prix compris entre 100 et 200, tandis que T|XS|S signale que les tailles XS ou S sont acceptées. La demande reste compacte, mais elle devient beaucoup plus simple à traiter.
/*
Dans cet exemple, la syntaxe choisie rend la saisie facile à découper. Les regex ne devinent pas l’intention de l’utilisateur : elles reconnaissent les conventions que nous avons définies.
*/
const recherche = 'P100-200 T|XS|S';
const prix = recherche.match(/\bP(\d+)-(\d+)\b/);
const tailles = recherche.match(/\bT\|([A-Z|]+)\b/);
if (prix) {
const criterePrix = {
critere: 'prix',
minimum: Number(prix[1]), // 100
maximum: Number(prix[2]) // 200
};
// criterePrix devient :
// { critere: 'prix', minimum: 100, maximum: 200 }
}
if (tailles) {
const critereTailles = {
critere: 'taille',
valeurs: tailles[1].split('|') // ['XS', 'S']
};
// critereTailles devient :
// { critere: 'taille', valeurs: ['XS', 'S'] }
}
/*
Dans cet exemple, la syntaxe choisie rend la saisie facile à découper. Les regex ne devinent pas l’intention de l’utilisateur : elles reconnaissent les conventions que nous avons définies, puis les transforment en critères exploitables par l’application.
*/Ce principe peut aller un peu plus loin. Dans un moteur de recherche interne, on pourrait imaginer une syntaxe comme +cuir -rouge & prix >= 50 & prix <= 600 & long > 20 & larg <= 30. Le +cuir indique un terme attendu, -rouge un terme à exclure, tandis que les conditions sur le prix, la longueur ou la largeur précisent les contraintes numériques. Nous ne sommes plus dans une phrase à interpréter, mais dans une suite de critères que l’application peut découper, vérifier, puis transformer en requête ou en filtre.
Ce type de solution est particulièrement pertinent lorsque l’application s’adresse à des utilisateurs réguliers, à une équipe métier ou à un espace d’administration. On peut afficher quelques exemples sous le champ de recherche, proposer une aide contextuelle ou documenter les opérateurs disponibles. Le champ reste libre, mais il n’est plus totalement imprévisible. Il devient une interface compacte entre l’utilisateur et la logique de l’application.
Il faut cependant bien placer cette approche. Elle est utile lorsque nous voulons structurer une saisie libre, mais elle ne remplace pas toutes les décisions métier. Dans un outil de planning, par exemple, les disponibilités, les salles, les véhicules ou les durées peuvent déjà être stockés sous forme de données structurées. Le problème n’est alors pas de décoder une saisie, mais de combiner correctement ces données pour trouver une solution acceptable. Le pseudo-langage sert donc surtout lorsque l’utilisateur doit exprimer des critères dans un champ compact.
Cette approche a aussi ses limites. Elle ne convient pas toujours à un public occasionnel, qui risque de ne pas comprendre la syntaxe ou de l’utiliser de manière irrégulière. Elle demande également de prévoir des messages d’erreur clairs lorsque la recherche est mal formulée. Mais dans certains contextes, ce petit langage contrôlé évite d’intégrer une IA simplement pour interpréter des demandes qui pourraient être exprimées de manière plus structurée. Plutôt que de demander à la machine de tout comprendre, nous pouvons parfois aider l’utilisateur à formuler plus clairement ce qu’il cherche.
L’IA comme outil de conception
L’IA n’a pas forcément besoin d’être intégrée dans l’application finale pour être utile. Elle peut intervenir plus tôt, pendant la conception du traitement, comme un assistant de réflexion et de développement. Cette distinction est essentielle. Nous pouvons utiliser l’IA pour explorer une logique, tester une idée ou améliorer une règle, sans faire dépendre l’application d’un modèle d’IA à chaque utilisation. Pour approfondir cette idée des différentes briques voir « IA conversationnelle, assistants, agents, workflows : comprendre les briques derrière les outils ».
Dans un projet concret, l’IA peut aider à formuler une règle métier, proposer une première expression régulière, améliorer une fonction ou générer des jeux de test. Elle peut aussi faire apparaître des cas limites auxquels nous n’avions pas pensé. Faut-il partir d’une liste de mots-clés ? Pondérer certains termes ? Ajouter un seuil de confiance ? Prévoir une catégorie “à analyser manuellement” ? Ce travail d’exploration peut accélérer la réflexion, à condition de ne pas confondre proposition et validation.
À ce stade, le “code” le plus utile n’est pas forcément une fonction. Il peut s’agir d’une consigne de travail adressée à l’IA pour explorer le problème avant de figer la logique applicative.
Je conçois une fonction qui oriente une demande utilisateur vers une catégorie :
création de site, maintenance, formation, automatisation, intelligence artificielle,
problème technique ou à analyser manuellement.
Propose :
- une liste de mots-clés par catégorie ;
- quelques regex utiles ;
- des cas ambigus à tester ;
- des exemples de demandes qui devraient rester sans décision automatique.La réponse obtenue ne doit pas être copiée telle quelle. Elle sert de matière première : nous la relisons, nous la testons, nous la simplifions, puis nous décidons ce qui mérite réellement d’entrer dans l’application.
- les mots-clés sont-ils adaptés au vrai vocabulaire des utilisateurs ?
- certaines catégories se recouvrent-elles trop ?
- les regex sont-elles trop larges ou trop strictes ?
- le seuil de confiance évite-t-il les décisions fragiles ?
- quels cas doivent rester soumis à une analyse humaine ?L’IA peut aussi être utile pour réfléchir à un problème de contraintes. Si nous devons concevoir un outil de planning, elle peut nous aider à lister les paramètres à prendre en compte : disponibilités, durées, salles, déplacements, véhicules, priorités, incompatibilités, marges de sécurité. Elle peut également faire apparaître des situations limites : deux professionnels disponibles mais aucune salle libre, un véhicule disponible mais trop éloigné, une réunion possible mais sur un créneau trop court. Ici encore, l’IA accompagne la conception du raisonnement ; elle ne devient pas forcément le moteur de décision de l’application.
Prenons le cas d’une regex ou d’un pseudo-langage de recherche. Demander à une IA de proposer une expression régulière pour reconnaître P100-200, P>200 ou T|XS|S peut être très utile. Mais cette proposition doit ensuite être relue, testée, simplifiée si nécessaire et adaptée aux contraintes réelles de l’application. L’IA peut produire une piste. Elle ne remplace pas la responsabilité du développeur, qui doit vérifier ce que la fonction accepte, ce qu’elle refuse, et ce qui risque de produire un résultat inattendu.
La démonstration Orientation automatique d’une demande utilisateur illustre bien cette séparation. Une IA pourrait aider à imaginer les catégories, les mots-clés, les regex ou les cas limites. Mais dans la version v1, l’orientation elle-même reste prise localement, dans le navigateur, à partir de règles visibles, de motifs détectables et d’un score de confiance. On peut d’ailleurs aller un peu plus loin dans la réflexion : ces listes (catégories, règles de mots-clés et expressions régulières, comme dans le code JavaScript présenté) pourraient ne pas être figées dans le code, mais devenir dynamiques en étant stockées dans une base de données. Cela ouvrirait la possibilité de les faire évoluer sans modifier l’application elle-même, simplement en ajustant les règles au fil des usages et des besoins.
const categories = [
'création de site',
'maintenance',
'formation',
'automatisation',
'intelligence artificielle',
'problème technique',
'indéterminé'
];
/**
* 3. Règles par mots-clés.
* Chaque mot-clé ajoute des points à une catégorie.
* Le poids peut être ajusté selon l’importance du signal.
*/
const keywordRules = [
{
category: 'création de site',
keywords: ['creer un site', 'creation de site', 'site vitrine', 'site internet', 'refonte', 'nouveau site'],
weight: 3
},
{
category: 'maintenance',
keywords: ['maintenance', 'mise a jour', 'sauvegarde', 'securite', 'lent', 'optimisation', 'corriger'],
weight: 2
},
{
category: 'formation',
keywords: ['formation', 'apprendre', 'atelier', 'initiation', 'cours', 'accompagnement'],
weight: 3
},
{
category: 'automatisation',
keywords: ['automatiser', 'automatisation', 'workflow', 'envoyer automatiquement', 'tache repetitive', 'formulaire'],
weight: 3
},
{
category: 'intelligence artificielle',
keywords: ['ia', 'intelligence artificielle', 'chatgpt', 'assistant', 'modele de langage'],
weight: 4
},
{
category: 'problème technique',
keywords: ['erreur', 'bug', 'probleme', 'ne fonctionne plus', 'fatal error', 'page blanche', 'php'],
weight: 3
}
];
/**
* 4. Expressions régulières.
* Elles servent à détecter des formes précises :
* erreur PHP, adresse e-mail, CSV/JSON, mention d’IA.
*/
const regexRules = [
{
label: 'Erreur PHP détectée',
category: 'problème technique',
regex: /\b(php\s+(fatal\s+)?error|warning|notice|parse error)\b/i,
weight: 5
},
{
label: 'Adresse e-mail détectée',
category: 'automatisation',
regex: /\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/i,
weight: 1
},
{
label: 'Mention CSV ou JSON détectée',
category: 'automatisation',
regex: /\b(csv|json)\b/i,
weight: 3
},
{
label: 'Demande liée à l’IA détectée',
category: 'intelligence artificielle',
regex: /\b(ia|intelligence artificielle|chatgpt|assistant)\b/i,
weight: 5
}
];Cette manière d’utiliser l’IA est souvent plus raisonnable que de l’embarquer immédiatement dans le produit final. Elle permet de profiter de sa capacité à générer des idées, reformuler, varier les cas et accélérer certaines tâches, tout en conservant une application plus simple, plus prévisible et plus facile à maintenir. L’IA devient alors un outil de conception, pas nécessairement un moteur de décision.
Quand l’IA devient-elle réellement pertinente ?
Il existe pourtant des situations où l’IA devient réellement intéressante. C’est le cas lorsque les données sont très hétérogènes, lorsque les formulations sont imprévisibles, ou lorsque les règles ne peuvent pas être entièrement écrites à l’avance. Si deux utilisateurs expriment le même besoin avec des mots très différents, si une demande dépend fortement du contexte, ou si le volume de textes rend impossible une analyse humaine régulière, une approche plus avancée peut se justifier.
L’IA devient surtout pertinente lorsque le traitement ne consiste plus seulement à repérer des mots, mais à interpréter une intention. Comme nous l’avons déjà abordé, une demande comme “mon site ne me correspond plus” peut difficilement être réduite à un mot-clé unique. Elle peut évoquer une refonte graphique, un repositionnement éditorial, un problème d’image, une évolution de l’activité ou un besoin d’accompagnement. Dans ce type de situation, la difficulté n’est pas seulement technique. Elle tient au sens, au contexte et parfois aux non-dits.
/*
Une manière raisonnable d’intégrer l’IA consiste à ne pas l’appeler dès le départ. L’application peut d’abord calculer un score, vérifier si la décision est suffisamment fiable, puis escalader seulement les cas faibles ou ambigus.
*/
const analyse = {
meilleureCategorie: 'maintenance',
score: 4,
secondScore: 3,
seuilMinimum: 3,
ecartMinimum: 2
};
const scoreTropFaible = analyse.score < analyse.seuilMinimum;
const decisionAmbigue = (analyse.score - analyse.secondScore) < analyse.ecartMinimum;
if (scoreTropFaible || decisionAmbigue) {
// Ici, l’application ne décide pas automatiquement.
// Elle peut demander une analyse humaine
// ou déclencher une analyse IA si le volume le justifie.
analyse.action = 'escalade';
} else {
// La logique simple suffit.
analyse.action = 'orientation automatique';
}
// analyse.action vaut ici : 'escalade'
/*
Ce fragment ne montre pas un appel à une IA. Il montre plutôt le point de bascule : le moment où l’application reconnaît que sa logique simple ne suffit plus à décider proprement.
*/Il faut toutefois distinguer un problème ambigu d’un problème fortement contraint. Un planning complexe, avec plusieurs professionnels, des salles, des véhicules et des créneaux à coordonner, peut demander un algorithme avancé sans nécessiter d’IA générative. La difficulté tient alors à l’optimisation et à la combinaison des contraintes, pas à l’interprétation d’un langage naturel. Dans ce cas, le bon outil peut être un moteur de règles, un algorithme de contraintes ou une logique de priorité, plutôt qu’un modèle chargé de “comprendre” une demande.
Même lorsqu’un besoin semble compatible avec l’IA, il peut être préférable de commencer par une première couche plus simple : nettoyage du texte, détection de motifs, score par catégorie, seuil de confiance, puis escalade uniquement lorsque le résultat reste incertain. Cette architecture évite de solliciter l’IA pour des cas évidents, tout en la réservant aux situations où elle apporte réellement quelque chose. L’IA n’est plus alors une réponse automatique, mais une étape possible dans une chaîne de décision.
La démonstration Orientation automatique d’une demande utilisateur illustre cette logique de première couche. La version v1 ne fait pas appel à une API d’intelligence artificielle : elle applique des règles, calcule un score et renvoie vers une analyse manuelle lorsque la décision paraît trop faible ou trop ambiguë. C’est précisément ce type de seuil qui permet ensuite de décider, dans une version plus avancée, si une intervention humaine ou une analyse IA devient utile.
La pertinence de l’IA dépend donc moins de l’apparence du problème que de sa nature. Un texte libre n’impose pas toujours de l’IA. Une décision complexe ne l’exige pas toujours non plus. En revanche, lorsque les règles sont instables, que le contexte compte beaucoup, que les formulations varient fortement et que les cas ambigus deviennent nombreux, l’IA peut devenir une solution à envisager sérieusement. Elle intervient alors non pas parce qu’elle est disponible, mais parce que le problème dépasse ce qu’une logique simple peut traiter correctement.
Exemple concret : orienter une demande entrante
Imaginons maintenant une application qui reçoit une demande saisie librement par un utilisateur. Cette demande doit être orientée vers une catégorie afin d’être traitée plus facilement : création de site, maintenance, formation, automatisation, intelligence artificielle, problème technique ou analyse manuelle. À première vue, on pourrait se dire qu’il faut comprendre le texte, donc intégrer une IA. Mais avant cela, nous pouvons construire une première couche de décision beaucoup plus simple.
La première étape consiste à préparer la saisie. On peut passer le texte en minuscules, supprimer les accents, retirer certains caractères inutiles, réduire les espaces multiples et isoler quelques éléments reconnaissables. Cette étape ne décide rien à elle seule. Elle évite simplement que deux formulations très proches soient traitées différemment à cause d’une majuscule, d’un accent ou d’un espace en trop.
/*
Avant de chercher des mots-clés ou des motifs, nous stabilisons la saisie. Le traitement suivant ne comprend pas encore la demande ; il prépare seulement un texte plus régulier pour la suite.
*/
function normalizeText(text) {
return text
.toLowerCase()
.normalize('NFD')
.replace(/[\u0300-\u036f]/g, '')
.replace(/[’']/g, ' ')
.replace(/[^a-z0-9@._%+\-\s]/g, ' ')
.replace(/\s+/g, ' ')
.trim();
}
const demande = 'J’ai une erreur PHP Fatal error sur mon site WordPress.';
const texteNormalise = normalizeText(demande);
// Avant traitement :
// 'J’ai une erreur PHP Fatal error sur mon site WordPress.'
// Après normalisation :
// 'j ai une erreur php fatal error sur mon site wordpress'
/*
Cette étape paraît modeste, mais elle rend la suite beaucoup plus fiable. Les comparaisons deviennent plus simples, et les règles ne dépendent plus autant des variations de saisie.
*/Une fois le texte stabilisé, nous pouvons chercher des indices. Certains mots ou expressions orientent naturellement la demande : “site vitrine”, “refonte” ou “nouveau site” peuvent évoquer la création de site ; “bug”, “erreur”, “page blanche” ou “fatal error” peuvent signaler un problème technique ; “cours”, “atelier” ou “apprendre” peuvent pointer vers la formation. Des regex peuvent compléter ce travail pour repérer des formes plus précises, comme une adresse e-mail, une mention de CSV ou JSON, une erreur PHP ou une demande liée à l’IA.
À partir de ces indices, l’application calcule un score par catégorie. Chaque mot-clé ou motif détecté ajoute un certain nombre de points. Si une catégorie dépasse clairement les autres, la demande peut être orientée automatiquement. Si plusieurs catégories obtiennent des scores proches, ou si le score reste trop faible, la demande est renvoyée vers une analyse manuelle. C’est ici que le seuil de confiance devient important : il évite de transformer une supposition fragile en décision automatique.
La démonstration Orientation automatique d’une demande utilisateur reprend cette logique dans une interface volontairement simple. La version v1 fonctionne sans API d’intelligence artificielle : elle normalise le texte, applique des règles par mots-clés, utilise quelques expressions régulières, calcule un score, puis renvoie vers une analyse manuelle lorsque la décision paraît trop faible ou trop ambiguë.
Ce mini-projet peut ensuite évoluer sans changer de logique. Une version v2.1 pourrait stocker les catégories, mots-clés et règles en base de données. Une version v2.2 pourrait ajouter une interface d’administration pour les modifier sans toucher au code. Une version v2.3 pourrait permettre d’ajouter de nouvelles catégories, règles ou pondérations au fil des usages. L’idée reste la même : commencer par une logique explicite, observable et ajustable, puis réserver l’IA aux cas où l’ambiguïté ou le volume le justifient réellement.
Une grille simple pour choisir l’outil
Pour éviter le réflexe automatique, nous pouvons retenir une grille de décision simple. Elle ne remplace pas l’analyse du besoin, mais elle aide à poser les bonnes questions au bon moment. Avant de choisir une solution, nous devons regarder la forme des données, la stabilité des règles, le niveau d’ambiguïté, le volume à traiter et le degré de risque associé à la décision.
- Un besoin fondé sur des règles claires et stables appelle souvent un algorithme classique.
- Un format reconnaissable peut être traité par une expression régulière.
- Une saisie libre, mais que l’on peut cadrer par une convention, peut donner lieu à un pseudo-langage de recherche.
- Des données bien structurées peuvent être orientées par des conditions, des pondérations ou un système de score.
- En revanche, des données ambiguës, très libres ou fortement dépendantes du contexte peuvent nécessiter une analyse humaine ou une IA, selon le volume et les enjeux.
Cette grille doit aussi laisser une place à l’IA comme outil de développement. Si le besoin est ponctuel, par exemple générer une regex, améliorer une fonction, explorer des cas limites ou reformuler une règle métier, l’IA peut être utilisée en amont sans être intégrée dans l’application finale. C’est souvent une solution plus sobre : nous profitons de l’assistance de l’IA tout en conservant un traitement applicatif explicite et maîtrisable.
| Situation Ce que nous observons | Solution probable Premier outil à envisager | Point de vigilance Ce qu’il faut vérifier |
|---|---|---|
| Règles claires et stables | Algorithme classique | Décrire les conditions, l’ordre des étapes et les cas limites. |
| Format reconnaissable | Expression régulière | Ne pas confondre détection de motif et compréhension du sens. |
| Saisie libre mais cadrable | Pseudo-langage de recherche | Documenter la syntaxe, prévoir des exemples et gérer les erreurs de saisie. |
| Données bien structurées | Conditions et score | Définir un seuil de confiance et une sortie par défaut. |
| Contraintes métier nombreuses mais structurées | Règles métier, algorithme de décision ou optimisation | Bien modéliser les ressources, les priorités, les conflits et les cas impossibles. |
| Données ambiguës ou fortement contextuelles | Analyse humaine ou IA éventuelle | Identifier ce qui rend la décision incertaine avant d’automatiser. |
| Grand volume de textes libres | IA envisageable | Évaluer le coût, la fiabilité, la confidentialité et la maintenance. |
| Besoin ponctuel de code ou de conception | IA comme assistant de développement | Relire, tester et adapter la proposition générée avant de l’intégrer. |
Cette grille n’a pas pour but de désigner une solution unique dans tous les cas. Elle sert plutôt à éviter une confusion fréquente : croire qu’un besoin qui paraît intelligent doit forcément être traité par de l’intelligence artificielle. Dans beaucoup de projets, la bonne solution consiste à combiner plusieurs niveaux :
- une règle simple quand elle suffit,
- une regex quand le motif est stable,
- un pseudo-langage lorsque la saisie peut être cadrée,
- un score quand plusieurs indices doivent être pondérés,
- puis une intervention humaine ou IA lorsque l’ambiguïté devient réelle.
Conclusion : L’IA n’est pas toujours là où on l’attend
L’IA peut être précieuse, mais elle n’a pas toujours besoin d’être au cœur du produit final. Elle peut aider en amont, lorsque nous concevons un algorithme, cherchons une regex, générons des jeux de tests ou explorons des cas limites. Elle peut aussi intervenir dans l’application lorsque le volume, la variété ou l’ambiguïté des données le justifient réellement. Mais elle ne devrait pas devenir une réponse automatique dès qu’un traitement doit trier, choisir, orienter, afficher ou proposer.
Choisir le bon outil, ce n’est pas opposer l’IA aux approches classiques. C’est accepter que chaque solution ait son terrain naturel. Un algorithme bien conçu, une expression régulière bien ciblée, un pseudo-langage de recherche ou un système de score peuvent rendre une application plus fiable, plus lisible et plus facile à maintenir. Et lorsque l’IA devient nécessaire, elle s’intègre alors dans une logique déjà pensée, au lieu de masquer un besoin qui n’a pas encore été clarifié.
