Après avoir abordé les fondements théoriques, il s'agit maintenant de découvrir les outils d'IA disponibles, de comprendre comment choisir un modèle ou un service adapté à un cas d'usage professionnel, et d'appliquer les bonnes pratiques pour interroger une IA ou trouver des informations pertinentes.
L'objectif est de développer les compétences pratiques pour naviguer dans le paysage des solutions d'IA et d'apprendre à exploiter ces technologies de manière efficace et réfléchie.
Le paysage des outils d'intelligence artificielle est très vaste.
On peut classer les solutions en plusieurs catégories, chacune avec ses avantages et inconvénients :
En pratique, aucune approche n'est universellement meilleure qu'une autre : tout dépend du contexte et des priorités de l'organisation. D'ailleurs, de nombreuses entreprises combinent les approches -- par exemple, utiliser un service cloud pour certaines tâches tout en exploitant des modèles open source en interne pour d'autres. Nous allons maintenant voir comment choisir judicieusement une solution en fonction d'un projet précis.
Lorsqu'un professionnel doit sélectionner un outil ou un modèle d'IA pour un projet, il ne faut surtout pas se baser uniquement sur la performance brute annoncée.
De nombreux critères doivent entrer en ligne de compte.
Voici les principaux éléments à considérer :
En synthèse, choisir une solution d'IA, c'est faire un équilibre entre performance, coûts, contraintes techniques et risques. Il n'y a pas de solution parfaite dans l'absolu : le "meilleur" modèle dépend toujours du contexte. Un projet pourra privilégier la rapidité de déploiement, un autre la maîtrise des données, un autre le faible coût, etc. Par exemple, une petite entreprise sans spécialiste IA préférera un service cloud clé en main même s'il est cher, tandis qu'une grande entreprise avec des exigences de confidentialité fortes investira dans une solution interne contrôlée de bout en bout.
Pour illustrer comment ces choix d'outils et de modèles se manifestent dans la pratique, examinons quelques cas d'usage concrets en informatique. Ces exemples montrent comment l'IA peut s'appliquer à des problèmes typiques du secteur TSSR/AIS, et quel type de solution serait adapté dans chaque cas.
Imaginons que vous gériez un réseau informatique ou un système de serveurs, et que vous souhaitiez détecter automatiquement des anomalies ou incidents (pannes, attaques, comportements anormaux) parmi une masse de données de journalisation (logs), de métriques ou de trafic réseau. La détection d'anomalies par IA consiste à apprendre ce qui est un comportement "normal" pour mieux repérer les écarts inhabituels. Concrètement, un modèle peut analyser des historiques de métriques (CPU, mémoire, trafic) ou de logs et apprendre des schémas de référence. Ensuite, si un jour l'activité sort de ces limites (ex : un trafic web subitement trois fois plus élevé que la normale à 3h du matin), l'IA le signale comme anomalie.
Plusieurs approches sont possibles : des méthodes de Machine Learning supervisé où l'on étiquette au préalable des exemples d'anomalies passées pour entraîner un modèle (par exemple un classifieur qui reconnaît les patterns de panne connus). Ou bien des méthodes non supervisées (très prisées en détection d'intrusion réseau) où le modèle, souvent un réseau de neurones ou un algorithme statistique, apprend tout seul les caractéristiques normales et remonte ce qui s'en écarte fortement. Par exemple, un auto-encodeur en deep learning peut être entraîné à reconstruire des données "typiques" et signaler une forte erreur de reconstruction pour un événement inhabituel, ce qui indique une anomalie. Il existe aussi des algorithmes classiques comme la forêt d'isolement ou le Local Outlier Factor pour repérer les points aberrants dans des données numériques.
Quels outils choisir ? Pour ce cas d'usage, on pourrait envisager un service cloud spécialisé : par exemple Azure propose un Détecteur d'anomalies prêt à l'emploi qui analyse vos séries temporelles et choisit automatiquement le meilleur algorithme pour détecter pics et creux anormaux. L'avantage est la simplicité (quelques lignes de code pour envoyer vos données et obtenir des alertes), et l'accès à des algos optimisés sans les implémenter vous-même. En revanche, cela implique d'envoyer vos métriques dans le cloud Azure. Si c'est un problème (données hautement sensibles ou réglementaires), on peut se tourner vers des outils open source. Par exemple, on peut déployer un outil de SIEM (Security Information and Event Management) couplé à de l'IA, ou utiliser la bibliothèque Python scikit-learn qui contient des implémentations de détection d'anomalies (IsolationForest, OneClass SVM, etc.). Des solutions open source dédiées existent aussi dans la communauté (par ex. la librairie pyOD pour "Python Outlier Detection"). L'avantage de la solution maison est le contrôle : on paramètre les seuils, on garde les données localement, on peut expliquer plus facilement aux équipes comment c'est configuré. L'inconvénient est qu'il faut plus de travail d'ingénierie pour arriver à un résultat fiable.
Dans la pratique, une approche hybride est possible : utiliser un modèle pré-entraîné pour une base de détection, mais affiner les alertes avec des règles métier ou des connaissances spécifiques de l'entreprise. Par exemple, l'IA détecte une hausse de trafic, mais c'est l'expert humain qui détermine si c'est une cyberattaque ou juste une promotion marketing qui a réussi (les anomalies ne sont pas toujours des incidents, elles peuvent révéler aussi des opportunités, comme l'indique IBM).
Ce cas montre l'importance de collaborer avec l'IA : l'outil repère des signaux faibles dans la masse de données, et les experts les analysent.
Les administrateurs systèmes et réseaux passent du temps à écrire des scripts (bash, PowerShell, Python...) pour automatiser des tâches : que ce soit un script de sauvegarde, un script de déploiement, de configuration d'un pare-feu, etc. Désormais, l'IA peut apporter une aide précieuse pour accélérer la création de ces scripts ou même les générer entièrement à partir d'une description en langage naturel.
Par exemple, avec un modèle de langage de type GPT, on peut demander : « Écris-moi un script Bash qui parcourt tous les fichiers d'un répertoire et envoie un e-mail s'ils dépassent une certaine taille ». En quelques secondes, l'IA peut proposer un script fonctionnel avec les commandes appropriées. Des outils spécialisés existent, comme GitHub Copilot (basé sur OpenAI Codex/GPT) qui s'intègre à un éditeur de code et suggère du code ou des scripts au fur et à mesure qu'on écrit. Microsoft a même introduit dans Windows des fonctions expérimentales où l'on peut générer des scripts PowerShell en décrivant ce qu'on veut faire en langage courant.
Quel modèle ou service pour cela ? Ici, les grands modèles de langage sont les plus indiqués. On peut utiliser un service en ligne comme ChatGPT (ou Claude, etc.) pour générer le script désiré. C'est souvent très efficace pour des scripts simples à modérés, et cela fait gagner du temps. Attention cependant : l'IA ne garantit pas la correction du script généré. Il arrive fréquemment que la réponse contienne des erreurs ou des oublis, surtout si la demande est complexe. L'IA peut suggérer une commande qui n'existe pas sur votre système, ou un paramètre obsolète. De plus, un modèle de langage n'admettra pas son ignorance : s'il ne sait pas, il inventera quelque chose qui a l'air plausible (on parle d'« hallucination » de l'IA) plutôt que de répondre qu'il ne sait pas. C'est pourquoi un script généré automatiquement doit toujours être testé et validé par l'administrateur avant usage en production.
On peut choisir d'utiliser l'API OpenAI (ou Azure OpenAI) avec un modèle spécialisé en code (par ex. code-davinci ou GPT-4 avec son mode code), ce qui offre potentiellement des résultats plus adaptés au code. L'avantage est d'obtenir des scripts souvent corrects et documentés. L'inconvénient est, encore une fois, la confidentialité : envoyer la description de votre infrastructure ou de votre problème à une IA cloud pose la question de ce qui est fait de ces données. Une parade peut être de formuler la demande de manière générique (ex : "script de sauvegarde réseau" sans exposer le nom de l'entreprise ou d'adresses IP sensibles) et d'assembler à la main les morceaux spécifiques après. Alternativement, il existe des modèles open source comme StarCoder ou CodeGen que l'on peut déployer en interne pour génération de code. Ils garantissent que le code ne sort pas de vos serveurs, mais peuvent être moins performants ou nécessiter une configuration plus compliquée.
Pour illustrer l'utilisation concrète, une entreprise pourrait tenir un assistant interne de code : un chatbot entraîné sur les bibliothèques maison et les exemples de scripts de l'entreprise, afin d'aider les techniciens. L'IA pourrait ainsi suggérer la bonne commande pour interroger un serveur Linux, générer un script de configuration Apache standard, etc. Les points forts sont un gain de temps et parfois la découverte de nouvelles approches (l'IA peut proposer une méthode qu'on ne connaissait pas). Les points faibles sont la fiabilité inégale et la nécessité que l'utilisateur maîtrise assez son sujet pour repérer si le script proposé est à côté de la plaque. Comme le résume un retour d'expérience : l'IA peut simplifier le travail et fournir des exemples concis, mais « il faut savoir poser la bonne question pour obtenir la réponse attendue, et la réponse n'est pas toujours juste ». Cet avertissement nous mène au thème suivant : comment bien interagir avec l'IA pour justement maximiser les bonnes réponses.
Un autre usage de plus en plus courant de l'IA en entreprise IT est la création d'un chatbot de support. Par exemple, un service informatique interne pourrait déployer un assistant virtuel capable de répondre aux questions fréquentes des employés (« Je n'arrive pas à configurer ma messagerie », « Comment changer mon mot de passe ? », « Le Wi-Fi ne fonctionne pas sur mon poste »...). De même, une entreprise qui propose un produit technique pourrait mettre en place un chatbot pour aider ses clients à résoudre des problèmes de premier niveau sans mobiliser directement un technicien humain.
Pour ce cas d'usage, on a besoin d'un modèle de langage conversationnel. Deux grandes approches se dessinent : utiliser un modèle généraliste prêt à l'emploi (comme GPT-4, ou un modèle open source déjà entraîné sur du langage naturel), ou créer/affiner un modèle spécialisé sur la base de connaissances technique de l'entreprise. La première option, GPT-4 via une API, donne un agent conversationnel très compétent en langue (compréhension fine des questions, capacité à enchaîner le dialogue). Il saura expliquer des concepts informatiques de manière claire, mais par défaut il ne connaît pas les spécificités de votre organisation (il ne sait pas quelle est la procédure interne précise pour réinitialiser tel accès, par exemple). On peut lui fournir du contexte à chaque question (par exemple en incluant dans le prompt un extrait du manuel interne pertinent), mais cela demande un certain travail d'ingénierie (c'est la technique du Retrieval Augmented Generation, où l'on fait chercher les infos à l'IA dans un document). La seconde option consiste à entraîner un chatbot sur vos données : soit par fine-tuning d'un modèle existant avec des données de support interne (historiques de tickets, FAQ maison, documentation technique), soit en entraînant depuis zéro un modèle (moins réaliste sauf pour des organisations très grandes, étant donné le volume de données requis). Un tel modèle aura l'avantage de parler le langage de l'entreprise et de connaître vos processus spécifiques. En revanche, il risque d'être moins performant en général (par exemple, GPT-4 a des connaissances encyclopédiques et d'excellentes capacités de raisonnement que votre modèle spécialisé n'aura peut-être pas). Le choix se fait souvent entre une solution généraliste vs. une solution spécialisée fine-tunée : par exemple, comparer l'utilisation directe d'un modèle GPT-4 à un chatbot entraîné sur la base de connaissances interne. Parfois, on utilise même les deux : GPT-4 sert de base, mais on lui injecte les données internes à la volée.
Quid des outils et plateformes ?
Là aussi, plusieurs possibilités. Des plateformes cloud offrent des services de chatbot clé en main où l'on alimente une FAQ et on obtient un bot (ex : IBM Watson Assistant, Microsoft Bot Framework avec QnA Maker, Dialogflow de Google, etc.). Ces solutions sont prêtes à l'emploi et ne demandent pas de savoir comment fonctionne le modèle en dessous. Vous fournissez des paires question/réponse ou un document, et le bot s'en sert pour répondre. L'inconvénient est que c'est souvent moins flexible et parfois limité à des réponses basées sur des correspondances de mots-clés (selon les générations de produits). À l'inverse, construire son propre chatbot avec un vrai modèle de langage open source (comme GPT-J, LLaMA-2 ou autres) offre plus de liberté, mais requiert de savoir le déployer (souvent sur un serveur avec GPU), et de programmer la logique de dialogue autour. Une troisième voie est de passer par un modèle open source hébergé par un tiers de confiance (par ex. certains fournisseurs français ou européens proposent des LLM hébergés en conformité RGPD, pour ceux qui ne veulent pas envoyer leurs données aux États-Unis).
Dans tous les cas, un point crucial pour un chatbot de support est la mise à jour des connaissances : l'IT évolue vite, les réponses du bot doivent être ajustées dès que les procédures changent ou que de nouveaux problèmes émergent. Si on a fine-tuné un modèle, il faudra périodiquement le ré-entraîner avec les nouvelles données, ce qui a un coût. Si on utilise une approche où le bot pioche dans une base de données (par exemple recherche dans la documentation à chaque question), il faudra simplement tenir à jour cette base -- ce qui est plus facile en continu. Ainsi, le choix du modèle influence aussi le flux de maintenance du projet sur le long terme.
Que ce soit pour un chatbot de support, pour générer un script ou analyser des données, la qualité des réponses de l'IA dépend directement de la qualité de la question posée.
Interagir avec une IA nécessite donc de bien formuler ses requêtes. Cela s'apprend : on parle souvent d'art du prompt (prompt engineering).
Voici quelques bonnes pratiques de "prompting" à adopter afin d'obtenir des résultats pertinents et fiables :
Pour illustrer l'impact de ces bonnes pratiques, on peut comparer un prompt mal formulé et un prompt bien formulé. Prenons le cas du script de pare-feu :
Il peut être très utile de rajouter des informations concernant le système d'exploitation utilisé, sa version (ex: Debian bookworm), où encore l'intégration de solutions tierces (fail2ban) afin de permettre la création éventuelles de tables etc.
Durant les cours, vous constaterez que des prompts bien pensés font une énorme différence dans la qualité des résultats obtenus. Nous sommes souvent surpris de voir à quel point reformuler ou ajouter un détail peut changer radicalement la réponse de l'IA.
D'où l'importance de maîtriser ce "langage de commande" qu'est le prompt.
Chaque question IMPOSE une réflexion en amont, et une structuration.