Apprendre la data science
sur de vraies données de forage.

La boue joue plusieurs rôles à la fois. Elle refroidit et lubrifie l'outil, elle contrôle la pression du réservoir en équilibrant la pression hydrostatique, elle stabilise les parois du puits, et elle remonte les cuttings jusqu'à la surface, où ils seront analysés par l'équipe de mud logging.

Le poids de la boue, sa densité, exprimée en kg/m³ ou en livres par gallon aux États-Unis, est l'un des paramètres les plus surveillés sur un chantier. Une boue trop légère ne compense pas assez la pression du réservoir, ce qui peut provoquer un kick. Une boue trop lourde peut au contraire fracturer la formation et provoquer des pertes de circulation.

Sur le terrain, le mud logger surveille ces paramètres en continu et croise les mesures de gaz remontés, la densité de la boue en entrée et en sortie, et le comportement du puits pour détecter tout signe précurseur d'un problème.

Chaque foreur suit en permanence quatre paramètres de forage qui, ensemble, racontent ce qui se passe au fond du puits sans qu'on ait besoin d'y descendre une caméra. Le ROP (Rate of Penetration) mesure la vitesse à laquelle l'outil avance dans la roche, généralement en mètres par heure. Le WOB (Weight on Bit) est le poids appliqué sur l'outil par la garniture de forage. Le RPM (Rotations Per Minute) est la vitesse de rotation de l'outil. Le torque (couple) mesure la résistance que l'outil rencontre en tournant.

Ces quatre paramètres sont liés. Augmenter le WOB pousse davantage l'outil dans la roche, ce qui devrait accélérer le ROP, mais seulement jusqu'à un certain point : au-delà, l'outil peut caler ou s'user plus vite sans gain de vitesse réel.

Le torque grimpe généralement avec le RPM et le WOB, mais une hausse anormale du torque sans changement des autres paramètres est un signal d'alerte : ça peut indiquer un frottement excessif contre la paroi du puits, un changement de lithologie, ou un début de coincement de la garniture.

Le mud logging repose sur deux sources d'information complémentaires qui remontent en continu à la surface : les gaz dissous dans la boue, et les cuttings, les fragments de roche ramenés par la circulation. Ensemble, ils permettent de reconstituer ce que traverse l'outil sans jamais le voir directement.

La chromatographie des gaz sépare et mesure en continu le méthane (C1), l'éthane (C2), le propane (C3), et les butanes (C4). Le mud logger calcule ensuite des ratios entre ces gaz, notamment le Wetness Ratio et le Balance Ratio, pour caractériser le type de fluide présent : un gaz sec (riche en C1) suggère un réservoir différent d'un gaz humide (riche en C3-C4), souvent associé à la présence d'huile.

En parallèle, l'analyse des cuttings à l'œil et au microscope binoculaire permet de décrire la lithologie traversée : couleur, texture, dureté, présence de fossiles ou de minéraux caractéristiques. Cette description est consignée mètre par mètre sur le log de mud logging, la mudlog, qui devient la mémoire géologique du puits.

Un kick survient quand la pression du réservoir dépasse la pression exercée par la colonne de boue, permettant à du fluide de formation (gaz, huile ou eau) d'entrer dans le puits. Non maîtrisé, un kick peut évoluer vers une éruption incontrôlée, l'un des incidents les plus graves en forage. Détecter les signes précurseurs tôt est donc une priorité absolue sur le chantier.

Les signes précurseurs les plus fiables sont : une augmentation du volume de boue dans les bacs de surface sans changement du débit de pompe, une hausse du débit de retour par rapport au débit injecté, une chute de la pression de pompe, et une augmentation du gaz total détecté par le mud logging. Aucun signe pris isolément n'est toujours concluant, c'est leur combinaison qui confirme le diagnostic.

Sur le plan de la pression, on distingue la pression normale (hydrostatique attendue) de la pression anormale, quand la pression de formation dépasse ce qui est prévu par la profondeur seule. Une zone à pression anormale non anticipée est l'une des causes les plus fréquentes de kick, d'où l'importance de la prédire avant même de forer, à partir de données sismiques et de puits voisins.

Face à un kick confirmé, l'équipe ferme le puits avec le BOP (blow-out preventer), le dispositif de sécurité en tête de puits, puis circule la boue contaminée en respectant une procédure stricte pour restaurer l'équilibre de pression avant de reprendre le forage.

Savoir chaque notion séparément ne suffit pas sur le terrain : un mud logger doit lire plusieurs courbes en même temps et reconstituer une histoire cohérente. Cette dernière leçon du module reprend un intervalle complet du puits 15/9-F-11 et te demande d'appliquer tout ce qu'on a vu jusqu'ici, dans l'ordre où un professionnel le ferait vraiment.

La méthode de lecture standard suit toujours le même ordre : d'abord la tendance générale (le ROP monte-t-il ou descend-il sur la durée ?), ensuite les paramètres de surface (WOB, RPM, torque bougent-ils en cohérence ou l'un d'eux diverge-t-il ?), puis les gaz (le niveau total et sa composition changent-ils ?), et enfin les cuttings (la lithologie décrite correspond-elle à ce que les courbes suggèrent ?). Un signal isolé ne veut souvent rien dire, c'est la cohérence entre ces quatre niveaux de lecture qui donne le diagnostic.

Sur l'intervalle étudié, 2 388 à 2 402 m, voici ce que montre le log du puits 15/9-F-11 : le ROP chute progressivement de 22 à 9 m/h, le WOB reste stable autour de 9 tonnes, le torque grimpe doucement de 11 à 15 kN·m, et le gaz total reste stable autour de 40 unités.

Avant de nettoyer ou d'analyser quoi que ce soit, il faut comprendre sous quelle forme les données de forage existent réellement. Ce ne sont pas des lignes isolées : ce sont des séries temporelles multivariées, plusieurs mesures (ROP, WOB, torque, gaz, gamma-ray) enregistrées en continu à intervalle régulier, souvent chaque seconde en temps réel, ou tous les quelques centimètres une fois converties en fonction de la profondeur plutôt que du temps.

Deux formats dominent l'industrie. Le format LAS (Log ASCII Standard) est le format historique pour les logs de puits : un fichier texte structuré, avec un en-tête décrivant chaque courbe (nom, unité, description) suivi des valeurs, indexées par profondeur. Le format WITSML (Wellsite Information Transfer Standard Markup Language) est plus récent, basé sur XML, et pensé pour la transmission en temps réel depuis le chantier vers des systèmes distants, avec une structure plus riche mais plus complexe à manipuler.

Une fois importées, ces données arrivent rarement prêtes à l'emploi. Il faut d'abord identifier l'index (profondeur ou temps), vérifier la fréquence d'échantillonnage de chaque courbe (elles ne sont pas toujours toutes à la même fréquence), et repérer les valeurs manquantes ou aberrantes qui seront traitées dans la prochaine leçon.

Les données de forage brutes ne ressemblent jamais aux courbes propres qu'on voit dans les manuels. Un capteur peut se déconnecter quelques secondes, la transmission peut perdre des paquets, les vibrations mécaniques du chantier ajoutent du bruit électrique, et certains outils produisent des valeurs aberrantes ponctuelles sans rapport avec la réalité géologique. Avant toute analyse, il faut distinguer ce qui est un vrai signal de ce qui est un artefact de mesure.

On distingue trois problèmes différents, qui se traitent différemment. Les valeurs manquantes sont des trous dans la série, souvent dus à une perte de transmission ou un capteur hors service. Le bruit est une variation rapide et aléatoire autour de la vraie valeur, causée par les vibrations ou les interférences électriques, mais qui n'a pas de sens géologique. Les valeurs aberrantes (outliers) sont des points isolés très éloignés de la tendance, qui peuvent être une erreur de capteur, ou au contraire un vrai événement brutal comme le début d'un kick.

Pour combler les valeurs manquantes, l'interpolation linéaire est la méthode la plus simple : elle relie les deux points valides encadrant le trou par une droite. Pour lisser le bruit sans perdre la tendance réelle, la moyenne mobile (rolling average) recalcule chaque point comme la moyenne des valeurs voisines sur une fenêtre glissante, par exemple les 5 dernières mesures.

Une fois les données nettoyées, avant de construire le moindre modèle, il faut comprendre comment les variables se comportent les unes par rapport aux autres. C'est le rôle de l'analyse exploratoire : visualiser plusieurs courbes côte à côte (affichage multi-log), et calculer une matrice de corrélation entre les paramètres pour repérer les relations statistiques.

Le coefficient de corrélation de Pearson, noté r, varie de -1 à 1. Proche de 0, il n'y a pas de relation linéaire ; proche de 1 ou -1, la relation est forte. Mais attention : une forte corrélation ne prouve jamais qu'une variable cause l'autre. Deux paramètres peuvent varier ensemble parce qu'un troisième facteur les influence tous les deux, comme un changement de lithologie ou une décision délibérée du foreur.

Le coefficient de détermination s'écrit R majuscule, avec un exposant 2 (R²), pour bien le distinguer du r minuscule vu juste avant : il s'obtient en élevant ce r au carré. Il indique la proportion de la variance d'une variable qui est statistiquement associée à l'autre. Un R² élevé signale une association forte, digne d'être creusée davantage, mais ne garantit pas un lien causal ou physiquement significatif à lui seul.

Repérer un pic isolé à l'œil, comme en Leçon 2, ne suffit plus à l'échelle d'un puits entier avec des dizaines de milliers de mesures. Il faut des méthodes systématiques, capables de balayer toute la série automatiquement. Deux grandes familles existent : les seuils statistiques, et les modèles de machine learning.

Le z-score mesure à combien d'écarts-types un point s'éloigne de la moyenne locale : z = (x − moyenne) / écart-type. Un seuil courant est |z| > 3 pour signaler une anomalie. La méthode IQR (écart interquartile) s'appuie plutôt sur la médiane et les quartiles, ce qui la rend plus robuste que le z-score quand les données ne suivent pas une distribution normale, puisqu'elle n'est pas influencée par les valeurs extrêmes de la même façon que la moyenne.

Quand les seuils simples ne suffisent plus, notamment parce que l'anomalie se cache dans la combinaison de plusieurs paramètres plutôt que dans un seul, les modèles de machine learning prennent le relais. L'isolation forest isole les points anormaux en mesurant combien de découpages aléatoires suffisent à les séparer du reste : une anomalie s'isole en peu d'étapes. Les autoencodeurs, des réseaux de neurones entraînés à reconstruire des données normales, signalent une anomalie quand l'erreur de reconstruction devient anormalement élevée.

Deviner la lithologie manuellement à partir des cuttings, comme en Leçon 3 du Module 01, prend du temps et dépend de l'expérience du mud logger. La classification supervisée automatise cette tâche : on entraîne un modèle à prédire une catégorie (grès, argile, calcaire...) à partir des courbes de log (gamma-ray, résistivité, densité, sonique), en lui montrant des exemples déjà étiquetés, généralement à partir de carottes ou de descriptions d'experts sur des puits antérieurs.

Les random forests et le gradient boosting dominent ce type de tâche sur des données tabulaires comme les logs de puits. Un random forest construit de nombreux arbres de décision légèrement différents (chacun entraîné sur un sous-échantillon aléatoire des données), puis fait voter tous les arbres pour la classe finale. Le gradient boosting construit ses arbres de façon séquentielle, chaque nouvel arbre corrigeant les erreurs des précédents.

Une fois le modèle entraîné, l'accuracy seule (le pourcentage de bonnes prédictions) peut être trompeuse, surtout quand une lithologie domine largement les autres dans le puits. La matrice de confusion détaille les prédictions correctes et les erreurs classe par classe, et permet de calculer la précision (parmi les prédictions "grès", combien sont vraiment du grès) et le rappel (parmi les vrais grès, combien ont été correctement identifiés).

Contrairement à la classification, qui prédit une catégorie, la régression prédit une valeur continue : ici, le ROP lui-même, à partir des autres paramètres (WOB, RPM, torque, lithologie). L'objectif n'est plus de deviner "quelle roche", mais "à quelle vitesse on va avancer", ce qui permet d'anticiper la durée d'un forage ou de détecter en amont une chute de performance anormale.

Une régression classique (linéaire, ou un random forest de régression) traite chaque mesure comme indépendante des autres. Mais le forage est une série temporelle : ce qui s'est passé il y a 10 mètres influence ce qui se passe maintenant. Les réseaux LSTM (Long Short-Term Memory) sont conçus pour capturer ce type de dépendance séquentielle, en gardant une forme de mémoire des mesures précédentes pour informer la prédiction actuelle.

Un piège fréquent en série temporelle est la fuite de données (data leakage) : diviser aléatoirement les données en entraînement et test, comme on le ferait pour des données non temporelles, laisse le modèle "voir" indirectement le futur pendant l'entraînement. La bonne pratique est de découper les données chronologiquement, entraîner sur le début du puits, tester sur la fin, jamais mélanger les deux.

Un modèle avec une bonne accuracy en laboratoire n'est pas automatiquement un bon modèle sur le terrain. En contexte industriel, toutes les erreurs n'ont pas le même coût. Un modèle de détection de kick qui déclenche une fausse alerte fait perdre quelques minutes à l'équipe pour vérifier. Un modèle qui manque un vrai kick peut mettre en danger le puits et l'équipage. Ces deux erreurs ne se valent pas, même si un tableau de métriques les traite souvent à égalité.

On distingue le faux positif (le modèle signale un problème qui n'existe pas) du faux négatif (le modèle ne signale rien alors qu'un vrai problème existe). Dans un contexte de sécurité comme la détection de kick, le faux négatif est presque toujours bien plus coûteux que le faux positif : une fausse alerte coûte du temps, un kick manqué peut coûter le puits.

Cette asymétrie de coût influence directement comment on règle un modèle. En abaissant le seuil de décision, un modèle détecte plus de vrais kicks (meilleur rappel) mais déclenche aussi plus de fausses alertes (précision plus faible). En contexte de sécurité, on accepte généralement de sacrifier de la précision pour maximiser le rappel : mieux vaut vérifier une fausse alerte de trop que manquer un vrai kick.

Le forage intelligent repose sur une capacité que les modules précédents ont supposée acquise : faire remonter des mesures depuis le fond du puits jusqu'à la surface, en temps réel, pendant que l'outil avance. Cette leçon ouvre la boîte noire de cette transmission, avant qu'on puisse parler d'automatisation ou de décision assistée par IA.

On distingue le MWD (Measurement While Drilling), qui mesure des paramètres physiques du forage lui-même (inclinaison, azimut, vibrations, chocs), du LWD (Logging While Drilling), qui mesure des propriétés géologiques pendant que l'outil avance (gamma-ray, résistivité, densité), l'équivalent en temps réel des logs qu'on étudiait au Module 01. Les deux sont intégrés dans le BHA (bottom hole assembly), l'ensemble d'outils juste au-dessus du trépan. La méthode de transmission la plus répandue reste le mud pulse telemetry : des impulsions de pression envoyées dans la colonne de boue elle-même, détectées en surface comme un signal binaire lent.

Une alternative existe : la télémétrie électromagnétique (EM), qui transmet un signal à travers la formation rocheuse elle-même plutôt que par la boue, avec un débit potentiellement plus élevé, mais une portée limitée par la résistivité de la formation traversée. Des solutions plus récentes comme le wired drill pipe (tiges de forage câblées) offrent un débit bien supérieur, au prix d'un équipement plus coûteux et plus complexe à déployer.

Une fois les mesures LWD disponibles en temps réel (Leçon 1), il devient possible d'ajuster la trajectoire du puits pendant qu'on fore, plutôt que de suivre un plan fixe établi avant le forage. C'est le geosteering : utiliser les logs qui remontent en direct pour rester dans la zone géologique visée, typiquement une couche réservoir de quelques mètres d'épaisseur, au lieu de la traverser ou de la manquer.

La méthode s'appuie sur la corrélation stratigraphique en temps réel : comparer les courbes qui remontent du puits en cours de forage à un modèle géologique de référence, généralement construit à partir de puits voisins déjà forés. Si la courbe de gamma-ray du puits en cours ressemble à celle d'un puits voisin à une profondeur donnée, on peut estimer où on se situe dans la couche cible, et ajuster l'angle de forage en conséquence avant de sortir du réservoir.

Rester dans la couche cible n'est pas qu'une question de précision géologique : chaque mètre foré hors de la zone productive est un mètre qui ne contribuera pas à la production, ou pire, un risque de sortir vers une zone à risque (aquifère, zone à pression anormale). Le geosteering vise donc à maximiser le temps passé dans la fenêtre géologique visée, ce qu'on appelle le taux de pénétration en zone (in-zone percentage).

Au Module 02, on a appris à prédire le ROP à partir des paramètres de forage. L'optimisation va plus loin : plutôt que de simplement anticiper ce que donnerait telle combinaison de WOB et RPM, il s'agit de rechercher activement la combinaison qui maximise la performance, en temps réel ou à partir de données historiques.

La méthode manuelle classique s'appelle le drill-off test : augmenter progressivement le WOB en gardant le RPM constant, observer la réponse du ROP, jusqu'à ce qu'il plafonne ou que l'outil commence à "flotter" (perte d'efficacité malgré le poids ajouté), ce qui marque le WOB optimal pour ce point précis. L'optimisation par machine learning automatise et généralise cette logique, à partir de modèles entraînés sur de nombreux puits passés, capturant des relations plus complexes (usure de l'outil, lithologie, limites mécaniques) qu'un seul test local ne peut révéler.

Maximiser le ROP seul n'est pas toujours le bon objectif. Pousser le WOB trop fort peut accélérer l'usure de l'outil ou provoquer des vibrations dommageables, augmentant le coût total malgré un forage plus rapide. La vraie fonction à optimiser est souvent le coût par mètre foré, qui combine le ROP avec le coût horaire du chantier et le coût des changements d'outil (trip cost) causés par une usure prématurée.

Les leçons précédentes du module ont porté sur des mesures et des ajustements pendant le forage réel. Le digital twin va plus loin : c'est une représentation numérique dynamique du puits, alimentée en continu par les données réelles, qui permet de simuler des scénarios avant même de les exécuter physiquement sur le chantier.

Un digital twin de puits combine plusieurs couches : un modèle géologique (issu des puits voisins et de la sismique), un modèle mécanique (comportement de la garniture de forage, contraintes), et les données temps réel du forage en cours (MWD/LWD, paramètres de surface). Contrairement à une simulation statique faite une seule fois avant le forage, le digital twin se recale en permanence : chaque nouvelle mesure réelle vient corriger ses prédictions, créant une boucle de rétroaction continue entre le monde physique et sa représentation numérique.

Un usage concret : avant d'ajuster un paramètre de forage (par exemple augmenter le WOB), l'équipe peut d'abord tester ce changement sur le digital twin, qui prédit l'impact probable sur le ROP, le torque et l'usure de l'outil, avant de l'appliquer réellement sur le chantier. Ça réduit le risque d'essais coûteux ou dangereux directement sur le puits réel.

Le NPT (Non-Productive Time) désigne tout le temps passé sur un chantier de forage sans progression utile : pannes d'équipement, coincements de garniture, attente de matériel, corrections de trajectoire imprévues, ou incidents de sécurité. Chaque heure de NPT coûte le tarif horaire complet du chantier sans faire avancer le puits d'un seul mètre, ce qui en fait l'une des cibles principales de toute stratégie de forage intelligent.

Les capteurs et modèles vus dans ce module (MWD/LWD, digital twin, ML) permettent de passer d'une réduction du NPT réactive (réagir après l'incident) à une réduction prédictive (anticiper avant qu'il survienne). Un modèle entraîné sur l'historique de nombreux puits peut par exemple détecter les signatures précoces d'un coincement de garniture (stuck pipe) dans les tendances de torque et de traînée, bien avant que l'incident ne devienne critique et n'immobilise le chantier.

Automatiser une partie du forage ne veut pas dire retirer l'humain de la boucle. La plupart des systèmes actuels restent supervisés : l'automatisation gère les ajustements fins et répétitifs (maintenir un WOB cible, ajuster le RPM), pendant que l'équipe garde la responsabilité des décisions à enjeu élevé (une alerte de kick, un changement de stratégie de trajectoire), avec toujours la possibilité de reprendre la main manuellement.

Ce module rassemble tout ce qu'on a vu dans les Modules 02 et 03, appliqué à un intervalle réel du puits 15/9-F-11 (2 320 à 2 360 m), mètre par mètre, comme le ferait un data scientist en poste. Pas de nouvelle notion ici : uniquement de la pratique, sur un pipeline complet du nettoyage à la recommandation.

Les modules précédents ont couvert la data science et le forage intelligent comme des disciplines à part entière. Ce module change d'angle : il regarde l'IA elle-même comme technologie transversale, au-delà des cas d'usage déjà vus, pour comprendre où elle en est réellement dans le secteur aujourd'hui, pas dans dix ans.

Quatre grandes familles d'IA sont concrètement déployées dans l'industrie extractive en ce moment. La vision par ordinateur analyse des images (carottes, cuttings, imagerie satellite) pour automatiser des tâches historiquement visuelles. L'IA générative produit du texte ou du contenu à partir de données existantes, notamment pour rendre exploitables des décennies de rapports géologiques papier ou scannés. L'IA agentique va au-delà de la prédiction pour percevoir, décider et agir de façon autonome sur une tâche définie. Et le forage automatisé, déjà couvert au Module 03, applique concrètement plusieurs de ces briques ensemble.

L'adoption de ces technologies n'est plus marginale. Un rapport 2025 mené par Ipsos pour VRIFY montre que 77% des entreprises d'exploration minière utilisent déjà l'IA à un certain niveau, et le forage autonome est déjà en opération commerciale sur des puits où l'économie le justifie (forages longue portée, chantiers à coût journalier élevé). Ces chiffres ne veulent pas dire que tout est automatisé partout, mais que l'IA est passée du stade expérimental au déploiement réel sur des cas ciblés.

La vision par ordinateur applique des modèles entraînés sur des images pour automatiser des tâches historiquement visuelles et manuelles. En pétrole et mines, ça couvre plusieurs usages concrets : la reconnaissance automatique de carottes et de cuttings, la classification d'images de diffraction (XRD) ou de fluorescence (XRF) pour identifier des minéraux, et la cartographie satellite ou hyperspectrale pour repérer des signatures minérales à la surface avant même de forer.

Ces modèles reposent souvent sur le transfer learning : plutôt que d'entraîner un réseau de neurones from scratch (ce qui demanderait des millions d'images annotées), on part d'un modèle déjà entraîné sur des images génériques, puis on l'affine sur un nombre bien plus restreint d'images géologiques spécifiques. Le modèle a déjà appris à reconnaître des textures, des contours, des motifs, il ne lui reste qu'à apprendre le vocabulaire visuel propre à la géologie.

Un usage particulièrement puissant combine vision par ordinateur et IA générative : des outils entraînés sur des millions de rapports géologiques, y compris des carnets de forage manuscrits et scannés, permettent de rendre exploitables des décennies de données dormantes dans des archives papier, un vrai problème pour une industrie qui accumule des rapports depuis plus d'un siècle.

Jusqu'ici, les modèles vus dans la formation prédisent (un ROP, une lithologie) ou classifient (un type de roche, une anomalie). L'IA générative fait autre chose : elle produit du contenu nouveau, du texte, en s'appuyant sur ce qu'elle a appris de vastes quantités de données existantes. Appliquée au secteur, ça donne des copilotes capables de lire, résumer, et répondre à des questions sur des documents techniques.

Le cas d'usage le plus concret concerne les rapports géologiques historiques. Des outils comme RadiXplore sont entraînés sur des millions de rapports, y compris des carnets de forage manuscrits et scannés, pour rendre exploitables des décennies de données dormantes que personne n'a le temps de relire manuellement. Un copilote peut aussi rédiger un premier jet de rapport de mud-logging à partir de notes brutes, ou répondre à une question précise en citant la bonne page d'un rapport de 200 pages, en quelques secondes plutôt qu'en heures de recherche manuelle.

Mais un copilote reste un outil, pas une source de vérité absolue. Ces modèles peuvent halluciner : produire une réponse plausible mais factuellement fausse, avec la même confiance apparente qu'une réponse correcte. Sur un rapport géologique de 200 pages, un copilote fiable doit toujours citer sa source précise (numéro de page, paragraphe), pour que l'utilisateur puisse vérifier plutôt que de faire confiance aveuglément.

On a mentionné l'IA agentique en Leçon 1 sans s'y attarder. Cette leçon creuse la distinction, essentielle pour comprendre où va réellement le secteur : un modèle prédictif (Module 02) répond à une question ponctuelle, un agent observe en continu, décide, et agit, dans une boucle qui ne s'arrête pas après une seule réponse.

Concrètement, un agent de forage suit ce cycle : il perçoit l'état actuel (les paramètres de forage en temps réel, vus au Module 03), décide d'une action (ajuster le WOB, par exemple), l'exécute, puis observe le résultat de cette action pour informer la décision suivante. C'est exactement la boucle qu'un foreur humain suit déjà manuellement ; l'agent l'automatise. Le forage autonome n'est plus une perspective lointaine : il est déjà en opération commerciale sur un sous-ensemble de puits où l'économie le justifie, notamment les forages longue portée et les chantiers à coût journalier élevé, où l'automatisation d'ajustements répétitifs libère l'équipe pour les décisions à plus forte valeur.

Un agent de forage autonome reste supervisé, comme on l'a vu au Module 03 pour l'automatisation en général : il gère les ajustements fins et répétitifs, mais une alerte de kick ou une décision à enjeu élevé remonte toujours à l'équipe humaine. Un standard de données ouvertes comme OSDU (Open Subsurface Data Universe) joue un rôle clé ici : en donnant un format commun aux données de puits entre opérateurs et fournisseurs, il permet à un agent de fonctionner de façon cohérente sur différents chantiers plutôt que d'être reconstruit à chaque fois pour un format propriétaire différent.

Après quatre leçons sur ce que l'IA permet de faire, cette dernière leçon du module porte sur ce qu'elle ne fait pas bien, ou pas encore, et sur les précautions à prendre avant de lui faire confiance dans un contexte industriel où les erreurs peuvent coûter cher, humainement et financièrement.

La rareté des données d'entraînement reste une limite réelle. Contrairement à des domaines comme la reconnaissance d'images grand public, entraînés sur des milliards d'exemples disponibles publiquement, les données de forage et de géologie spécifiques à un bassin ou une lithologie particulière restent souvent limitées, propriétaires, ou jamais numérisées. Un modèle entraîné sur peu de données généralise moins bien à des situations nouvelles, exactement le problème que le transfer learning (Leçon 2) atténue sans l'éliminer complètement.

L'interprétabilité est un autre défi : un modèle de deep learning complexe peut donner une bonne prédiction sans qu'on comprenne facilement pourquoi, ce qui pose problème quand une décision doit être justifiée (à un régulateur, à une équipe de sécurité). Le biais algorithmique est lié : si les données d'entraînement sur-représentent certains types de puits ou de conditions, le modèle héritera de ce déséquilibre, un peu comme la classe minoritaire vue au Module 02 pour la classification lithologique. Enfin, la gouvernance des données (qui a accès à quoi, comment les données sont sécurisées et tracées) devient centrale dès qu'un modèle influence des décisions opérationnelles réelles.

On a introduit la distinction entre modèle prédictif et agent au Module 05, Leçon 4. Cette leçon reprend l'idée, mais avec un objectif différent : ne plus seulement comprendre ce qu'est un agent, mais commencer à en construire un, précis, du début à la fin de ce module.

Trois niveaux à bien distinguer. Un chatbot répond à une question par une réponse, sans mémoire ni logique au-delà de l'échange en cours. Un modèle prédictif (comme ceux du Module 02) produit une prédiction ou une classification à partir de données, mais n'agit jamais lui-même. Un agent va plus loin : il perçoit un contexte, décide d'une action ou d'une réponse en fonction de règles précises qu'on lui donne, puis agit, potentiellement en utilisant des outils (function calling) comme aller chercher une donnée ou faire un calcul.

Dans ce module, tu ne vas pas construire un agent générique : tu vas concevoir précisément l'Assistant Mud-Logger, celui-là même qui t'a posé des questions dans les cartes assistant depuis le Module 01. Son rôle est fixé dès maintenant, et il sera identique pour chaque étudiant qui suit ce module : rester uniquement sur le sujet de la leçon en cours, ne jamais donner directement la réponse à une question de quiz mais guider par des indices, utiliser uniquement les données du puits fournies sans jamais en inventer, et rester concis. Cette spécification n'est pas un exemple parmi d'autres : c'est exactement le prompt que tu vas construire et tester dans les prochaines leçons.

La Leçon 1 a fixé le rôle et les règles de l'Assistant Mud-Logger. Concevoir l'agent, c'est l'étape suivante : décider concrètement de quoi il a besoin pour remplir ce rôle, avant même d'écrire la moindre ligne de code. Deux questions structurent cette conception : quelles informations l'agent doit-il connaître, et quelles actions doit-il pouvoir effectuer lui-même plutôt que de tout recevoir déjà mâché.

Jusqu'ici, dans les tests qu'on a faits, toutes les données du puits étaient écrites directement dans le prompt système, tout d'un coup. Ça fonctionne pour une seule leçon avec un intervalle limité, mais ça devient rapidement coûteux et rigide si l'agent doit couvrir tout un puits ou plusieurs puits. La conception d'un agent introduit une meilleure approche : donner à l'agent des outils (function calling), des fonctions précises qu'il peut appeler lui-même quand il en a besoin, comme récupérer les données d'un intervalle précis ou calculer une valeur, plutôt que de tout lui donner d'avance dans le prompt.

Pour l'Assistant Mud-Logger, deux outils suffisent pour couvrir l'essentiel de ce qu'on a vu dans la formation : get_well_data(profondeur_debut, profondeur_fin), qui retourne les paramètres de forage sur un intervalle donné, et calculer_mse(wob, rpm, torque, rop), qui applique directement la formule vue au Module 01. L'agent décide lui-même quand appeler chaque outil, en fonction de la question posée par l'étudiant.

La Leçon 2 a défini les deux outils de l'Assistant Mud-Logger sur le papier. Cette leçon montre comment ça se traduit concrètement dans un appel à l'API : le function calling n'est pas une fonctionnalité magique, c'est un mécanisme précis où on décrit les outils disponibles à Claude, et où le modèle décide lui-même s'il doit en appeler un avant de répondre.

Le flux complet suit quatre étapes. D'abord, on envoie la question de l'étudiant à l'API, accompagnée d'une description des outils disponibles (leur nom, ce qu'ils font, leurs paramètres). Ensuite, si Claude juge qu'un outil est nécessaire, il ne répond pas directement : il renvoie une demande d'appel d'outil, avec les paramètres qu'il a choisis. C'est alors le code de l'application (pas Claude) qui exécute réellement la fonction, par exemple en allant chercher les données du puits dans une base. Enfin, le résultat de cette exécution est renvoyé à Claude, qui l'utilise pour formuler sa réponse finale à l'étudiant.

Cette séparation a une conséquence de sécurité importante : puisque c'est le code de l'application qui exécute réellement chaque outil, c'est aussi lui qui peut vérifier et limiter ce que l'outil est autorisé à faire, avant même que le résultat ne parte vers Claude. Un outil get_well_data bien conçu ne devrait par exemple accepter que des profondeurs valides pour le puits en cours, pas n'importe quelle valeur.

Les outils vus en Leçon 3 permettent à l'agent de récupérer des données structurées (chiffres, mesures). Mais une partie importante de la connaissance du secteur existe sous forme de texte libre : rapports géologiques, procédures, notes de chantier, exactement le type de documents évoqués au Module 05 avec les copilotes. Le RAG (Retrieval Augmented Generation) est la méthode qui permet à l'agent de puiser dans ces documents plutôt que de se fier uniquement à sa mémoire d'entraînement.

Le principe suit trois étapes. D'abord, les documents (par exemple les rapports du puits 15/9-F-11) sont découpés en petits morceaux, puis indexés dans une base de recherche. Ensuite, quand l'étudiant pose une question, le système cherche les morceaux de texte les plus pertinents par rapport à cette question, pas le document entier. Enfin, ces extraits pertinents sont injectés dans le prompt envoyé à Claude, qui les utilise pour répondre, en citant sa source, exactement le principe de citation vérifiable vu au Module 05, Leçon 3.

Le RAG et le function calling (Leçon 3) se complètent, ils ne s'opposent pas. Les outils comme get_well_data conviennent aux données structurées et précises (une valeur à une profondeur donnée). Le RAG convient au texte non structuré (un rapport géologique en prose). Un agent bien conçu combine les deux : il appelle un outil pour un chiffre précis, et cherche dans les documents pour une explication contextuelle.

L'Assistant Mud-Logger est conçu (Leçon 2), techniquement construit (Leçon 3), et peut désormais s'appuyer sur de vrais documents (Leçon 4). Avant de le considérer prêt, il reste une étape que beaucoup de projets d'agents IA négligent : le tester délibérément sur ses points faibles, pas seulement sur les cas où on s'attend à ce qu'il réussisse.

Trois catégories de test à couvrir systématiquement. Les cas nominaux : l'agent répond-il correctement aux questions attendues, dans le style prévu (guider sans donner la réponse) ? Les cas limites : que fait l'agent face à une question hors sujet, une profondeur qui n'existe pas dans le puits, ou une donnée manquante ? Les tentatives de contournement : est-ce qu'un étudiant malin peut reformuler sa question pour obtenir la réponse directe malgré la règle fixée en Leçon 1, par exemple en demandant "donne-moi juste la bonne lettre" plutôt que d'expliquer le concept ?

Au-delà des tests ponctuels, un agent en production a besoin de garde-fous permanents : des limites strictes qui s'appliquent quoi qu'il arrive, indépendamment de ce que Claude "décide". Une limite de dépense maximale par étudiant (vue en pratique dans le test qu'on a fait sur ta clé API), une liste de sujets strictement interdits, ou une validation systématique des paramètres d'outils (vue en Leçon 3) en sont des exemples concrets. Ces garde-fous vivent dans le code de l'application, jamais uniquement dans le prompt, exactement pour la même raison que la validation des paramètres d'outils : un prompt peut être contourné, une limite codée en dur beaucoup plus difficilement.