L'invention concerne le suivi d'approvisionnement entre fournisseur (s) et client, pour des projets industriels, notamment mais non exclusivement des projets industriels lourds.

Dans certains domaines, l'approvisionnement en flux tendu peut se trouver à la fois critique, et particulièrement délicat à mettre en oeuvre. C'est le cas par exemple pour les forages pétroliers, et leur approvisionnement en tubes métalliques de divers types.

On sait faire en sorte que, sur le site de forage (site client), chaque puits de forage (ou projet) soit associé à un état daté de besoins en tubes métalliques (produits amont) de divers types et dimensions. En même temps, il est tenu un état des stocks de ces produits amont, tels qu'ils existent sur le site de forage. Les commandes sont passées au four- nisseur de tubes en fonction de ces états. Cependant, les délais de fabrication des tubes au niveau du fournisseur, et les délais de transit entre le site fournisseur et le site client conduisent d'une part à prévoir sur le site client et/ou sur le (s) site (s) fournisseur (s) des stocks assez importants pour faire face à tout imprévu ou à toute modifi- cation d'un projet en cours, et/ou d'autre part à accepter des retards dans l'exécution de ce projet. Ces contraintes sont lourdes dans un domaine comme celui des forages pétro- liers. Par ailleurs, il est difficile de gérer ces contrain- tes autrement que projet par projet.

La présente invention vient améliorer la situation.

Elle offre d'une part un procédé informatique de suivi d'approvisionnement en flux tendu entre fournisseur (s) et client, dans lequel, sur un site client, chaque projet (Pi)

est associé à un état daté de besoins (Ii, ti) en produits, en même temps qu'il est tenu un état des stocks (Sj, tj) et des achats (Ak, tk) de ces produits, caractérisé en ce qu'il comprend les étapes suivantes : a. établir une liste de types de produits (Ii) intervenant dans un ou plusieurs projets (Pi), b. pour chaque type de produit amont (Ii), établir, dans au moins une table (Bp, Rp), et pour une séquence de tran ches de temps, ayant une origine de temps choisie, * pour chaque tranche de temps, un premier cumul, depuis l'origine de temps jusqu'à la tranche de temps concernée, d'une première quantité (Bp) reliée aux besoins datés (Ii, ti) sur le site client, * pour chaque tranche de temps, un second cumul, depuis l'origine de temps jusqu'à la tranche de temps concernée, d'une seconde quantité (Rp) reliée aux stocks (Sj, tj) et aux achats (Ak, tk), les achats étant décalés temporellement en fonction d'un délai, et c. rechercher les temps auxquels les seconds cumuls de- viennent inférieurs aux premiers, comme indicateurs d'un risque de rupture d'approvisionnement et/ou d'une nécessité de déclenchement d'approvisionnement.

Par"achats", on peut entendre ci-dessus les achats réalisés, commandés, prévus, ou même simplement envisagés (besoins d'achats). L'une de ces options peut être choisie par construction. En variante, une ou plusieurs des options peuvent être rendues disponibles à l'utilisateur, au choix, selon le mode d'analyse désiré. Le délai peut être un délai d'approvisionnement, ou de disponibilité sur site, ou un délai relié à l'un et/ou l'autre de ceux-ci, directement ou indirectement.

L'invention offre, d'autre part, un système informatique de suivi d'approvisionnement en flux tendu entre fournisseur et client, comprenant un module de suivi (50,52) capable d'entretenir en mémoire un état daté de besoins en produits (Ii, ti), associé à un ou des projets (Pi), en même temps

qu'un état des stocks (Sj, tj) et des achats (Ak, tk) de ces produits, caractérisé en ce que le module de suivi comprend un module pilote (54), comportant : - un module de besoins (612a) capable, pour chaque type de produit, d'établir une première table, associée à une séquence de tranches de temps, ayant une origine de temps choisie, cette première table associant à chaque tranche de temps un premier cumul des besoins (Bp), depuis l'origine de temps jusqu'à la tranche de temps concernée, - un module de ressources (612b), capable, pour chaque type de produit, d'établir une seconde table, associée à la séquence de tranches de temps, cette seconde table associant à chaque tranche de temps un second cumul (Rp) de stocks plus achats, depuis l'origine de temps jusqu'à la tranche de temps concernée, les achats étant décalés temporellement en fonction d'un délai (DA ; DI), et - un comparateur (618) pour rechercher les temps auxquels les seconds cumuls deviennent inférieurs aux premiers, comme indicateurs d'un risque de rupture d'approvisionnement.

Ce qui précède est une vue fonctionnelle du système. Selon une autre vue, le module de suivi comprend : - un module de cumul (612), capable de recevoir pour paramè très la désignation d'un type de produit, d'un mode, ainsi que d'une origine de temps, et d'établir, pour le type de produit désigné, une table associant à des tranches de temps successives un cumul de quantités du produit, définies par le mode, chaque cumul allant depuis l'origine de temps jusqu'à la tranche de temps concernée, et - un module pilote (54), agencé pour : * appeler le module de cumul (612) avec un type de produit, et un mode comprenant le cumul besoins sur le site client, ce qui fournit une première table, * appeler le module de cumul (612) avec le même type de produit, et un mode comprenant le cumul stocks plus approvisionnements (par exemple, des livraisons), ce qui fournit une seconde table, et

* rechercher (618) les temps auxquels les cumuls de la seconde table deviennent inférieurs à ceux de la pre- mière table, comme indicateurs d'un risque de rupture d'approvisionnement.

Enfin, l'invention couvre également un programme-produit, qui peut être défini comme comprenant les fonctions pour exécuter les étapes a. à c. du procédé ci-dessus, et/ou comme compre nant les fonctions du module pilote dans le système défini ci-dessus.

L'invention peut encore couvrir un programme produit de niveau supérieur, formant précurseur du programme produit mentionné plus haut. Dans un mode de réalisation en program mation à objets, ce programme produit de niveau supérieur peut comprendre des classes-objet, et une version générique du module pilote.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : - les figures 1 et la représentent la structure générale connue d'un puits de pétrole, d'une façon schématique restreinte aux besoins de la présente description ; - la figure 2 est une vue en coupe illustrant l'assemblage, connu, de deux tubes ; - la figure 2a est une version modifiée de la figure 2 ; - la figure 3 est un schéma de flux illustrant la fabrication et l'assemblage d'éléments tels que ceux de la figure 2 ; - la figure 4 est un schéma illustrant l'interaction connue entre un site client et un site fournisseur ; - la figure 5 est une version modifiée selon l'invention du schéma de la figure 4 ; - la figure 6 illustre des fonctions implantées dans un système informatique ; - la figure 7 est un ordinogramme des opérations utilisées pour la mise en oeuvre de l'invention, dans un mode de réalisation ;

- la figure 8 est un graphique formant un premier mode de visualisation du produit de l'invention ; - la figure 9 est un tableau formant un second mode de visualisation du produit de l'invention ; et - la figure 10 est un schéma à objets illustrant une variante intéressante de l'invention.

Les dessins contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant.

La présente description est complétée d'une annexe, qui définit : - en A. 1.0 des notations, - en A. 1.1. des éléments de base pour la mise en oeuvre de l'invention, et - en A. 1.2. des objets logiciels ainsi que leurs propriétés, dans le cas d'une réalisation en programmation par objet.

Il pourra être fait directement référence aux sections de cette annexe, qui n'est mise à part que par souci de clarté, et fait partie intégrante de la description.

Le présent document peut contenir des éléments susceptibles d'une protection par droit d'auteur ou copyright. Le titu- laire des droits n'a pas d'objection à la reproduction à l'identique par quiconque de ce document de brevet, tel qu'il apparaît dans les dossiers et/ou publications des offices de brevet. Par contre, il réserve pour le reste l'intégralité de ses droits d'auteur et/ou de copyright.

La description détaillée ci-après sera faite principalement en référence au cas d'un site de forage pétrolier, à titre d'exemple non limitatif. Des appareils de forage ("rigs") sont utilisés pour produire du pétrole et du gaz, au niveau de chaque puits d'un site. Un tel puits est composé d'un assemblage de tubes en acier, de plusieurs types différents.

La figure 1 représente un puits en cours de forage avec plusieurs colonnes concentriques de tubes de cuvelage ("casings"), notés TO. Ces tubes TO apparaissent en traits noirs et sont entourés par du ciment CO en zone grisée. Au centre apparaît un train de tiges de forage T2 ("drill pipes"). Dans ce train de tiges descend de la boue de forage qui permet notamment d'évacuer les débris des roches forées.

Dans la zone Z2, on a par exemple en périphérie une jonction de cuvelage, et au centre une jonction de tige.

Sur la figure 1A, on retrouve le cuvelage, tubes TOI à T04, suspendus par des coins formant suspension de tubes de cuvelage ("Casing Hangers") CH1 à CH4, entourés de couches de ciment C01 à C04, dont chacun se termine en bas par un sabot de cimentation ("Cementing Shoe") CS01 à CS04. Le cuvelage se poursuit par un tube ("liner") L05, orienté selon la géomé- trie du réservoir et perforé, par exemple, en P05 pour laisser passer l'huile ou le gaz qui sera remonté par le tube de production ("tubing"). Le tube L05 est tenu par une suspension d'extrémité de cuvelage ("Liner Hanger") LH. La colonne de production est constituée par des tubes de production ("tubings") et par un certain nombre d'accessoires qui sont entre autre la vanne de sécurité ("Safety Valve") SV et une poche de stockage ("Side Pocket Mandrel") SPM, elles- mêmes encadrées par des adaptateurs (Cross-Over) CO ou par des tubes courts ("Pups-Joints") PJ ou encore par des adaptateurs hydrauliques ("Flow Couplings") FC.

La colonne de production est suspendue, en haut, par un coin ("Tubing Hanger") TH et comprend par ailleurs plusieurs obturateurs de fond de puits ("Paker"), comme par exemple PK et BP.

Bien entendu, la colonne de production n'est descendue qu'une fois le forage terminé et vient à la place du train de-tiges de forage.

Chaque puits nécessite donc différents types de tubes, qui doivent être fabriqués et assemblés sur des sites de produc tion de tubes, convoyés jusqu'au site de forage, où ils sont

assemblés sur une plus grande longueur dans le puits. En outre, chaque puits requiert également l'assemblage d'un certain nombre d'autres sous-ensembles ou accessoires, sur lesquels on reviendra.

La figure 2 fait apparaître deux tubes Ta et Tb, assemblés par un manchon fileté M. Au niveau de la production de tubes, on assemble un manchon M à une extrémité de tube, par exemple Ta. Les tubes sont alors transportés en longueur unitaire (de 10 m environ) avec une extrémité manchonnée. L'assemblage en grande longueur de l'extrémité libre du manchon avec l'extré- mité non manchonnée d'un autre tube se fait sous l'appareil de forage ou"rig", et généralement lors de la descente des tubes dans le puits.

La mise à disposition d'un produit tubulaire assemblé sur le site de forage fait intervenir de nombreuses opérations, que l'on décrira maintenant en référence à la figure 3, dont la partie gauche est une échelle de temps orientée vers le bas, d'un instant initial tfo, un peu postérieur à la réception d'une commande, à un instant final tfl, qui représente le moment où le produit tubulaire sera sur le site de forage.

Les tubes sont réalisés à partir d'une billette 301, soumise à une opération de laminage en 303, puis à un traitement thermique en 305, après quoi leurs extrémités sont filetées en 307 pour recevoir le manchon.

De son côté, le manchon est également fabriqué à partir d'une billette 311, laminé en 313, puis soumis à un traitement thermique en 315, après quoi il subit en 317 des opérations de tronçonnage et de filetage.

En 320, les tubes sont ensuite assemblés avec leurs manchons, comme illustré sur la figure 2, jusqu'à une longue dimension, définie par les contraintes limites de transport, et l'ensemble est conditionné pour le transport. L'opération finale de transport en 322 amène ces produits tubulaires sur le site de forage.

Une variante consiste à raccorder deux tubes sans manchon intermédiaire, comme illustré à la figure 2a. L'un des tubes reçoit un filetage mâle, l'autre un filetage femelle.

Schématiquement, dans la situation actuelle, un site four- nisseur SF réalise les opérations de fabrication de la figure 3 en SF1, et comporte également un stockage fournisseurs en SF2.

Du côté du site client SC, on a des projets SC1, en l'occurrence une pluralité d'opérations de forage, ainsi que des stocks de produits tubulaires SC2. Entre les deux sites est à prévoir un temps de transport Ttr. Du côté client, le stock SC2 est également alimenté par les reconditionnements de tubes en provenance des appareils de forage ou"rigs" (après usage). Ces produits remis en état ou reconditionnés redeviennent disponibles après contrôle. Cela est une source significative de variation des stocks.

En fait, les opérations sont un peu plus complexes, comme l'indique la figure 5.

Le fournisseur Fo va généralement utiliser plusieurs usines différentes et implanter à des endroits différents U1 à U (les laminoirs sont par exemple implantés en des sites fixes). Il va donc réaliser un planning de production fournisseurs Pfo, dans lequel il devra tenir compte de variations locales de production DTfo, éventuellement.

Du côté clients Cl, il existe également un planning de forage (production client) Pcl, ainsi que des variations locales du planning de forage DTcl.

L'interaction entre le site client et les sites fournisseur se produit par les opérations de transport de produits tubulaires TR.

Actuellement, les produits tubulaires sont livrés aux clients pétroliers soit à partir d'une mise en fabrication faisant

suite à une commande (qui nécessite un délai de réalisation de quatre à six mois), soit à partir d'un stock de consigna tion géré pour le compte de ce client. Ces contraintes temporelles et/ou de stockage, extrêmement lourdes, sont génératrices de coûts qu'il y a lieu de chercher à atténuer.

En particulier, s'est posé le problème pour le fabricant de tubes de livrer les produits tubulaires relatifs aux appa- reils de forage autant que possible sans stock intermédiaire, c'est-à-dire en"juste à temps". Il est également souhaitable de réduire le délai entre la confirmation de la commande et la livraison sur place à six semaines, tout du moins pour des tubes standards.

Bien entendu, les besoins en produits tubulaires peuvent évoluer considérablement en fonction de l'évolution de la situation sur le site de forage, elle même fonction d'événements qui peuvent aller de l'imprévu géologique et/ou de prospection à l'accident sur du matériel.

Il est envisageable de déléguer une personne sur le site de forage, ou près de celui-ci, afin de mettre à jour aussi régulièrement que possible les prévisions de consommation de tubes, de les consolider, et de les transmettre aux respon- sables de la planification des usines de fabrication de tubes.

Toutefois, lorsque le nombre d'appareils de forage devient élevé, et que les prévisions sont revues très fréquemment, il est humainement impossible d'actualiser les prévisions manuellement de manière fiable. De plus, le lien entre la fourniture des produits tubulaires et celle des accessoires associés devient très vite complexe.

La présente invention vient apporter une solution à ces problèmes.

Selon un aspect de l'invention, il est prévu sur les sites clients CL un système informatique CSc, de préférence lié par

réseau à un système CSf côté fournisseurs, pour une trans- mission rapide des informations.

Du côté du client, à un instant Ti, le besoin en produits Ii, pour un puits Pi peut être représenté par un triplet d'informations données en A. l. l. a. En fait, le besoin en produits Ii est une fonction du puits Pi et du temps, comme indiqué en A. l. l. b.

Du côté du fournisseur, on est en mesure, à un instant Tj, d'apporter au client un approvisionnement, à la suite duquel le client dispose d'une quantité totale Sj du produit Ij, comme indiqué en A. l. l. c (on appelle ci-après cette quantité totale"stock", bien qu'elle ne corresponde pas exactement à un stock physique).

Le problème d'optimisation posé consiste à partir des données Ii et Ti pour tous les puits, d'interagir en conséquence sur les stocks Sj au temps Tj.

La figure 6 illustre des fonctions implantées dans un ordinateur qui peut être par exemple un serveur WEB-IIS (Internet Information Service), exploité sous Windows NT.

En 50, la mémoire de l'ordinateur contient les quantités illustrées en A. l. l. a et A. l. l. c dans l'annexe, qui peuvent être respectivement vues comme les besoins par puits, et l'état du stock par produits (ITEMS). De façon connue, un système de saisie de données influe sur le contenu de la mémoire 50. Il peut être fondé sur des données saisies par opérateur, et/ou tirées des plannings informatiques du site.

Classiquement, les besoins sont gérés par puits. L'invention prévoit tout d'abord en 52 que l'on réalise une sommation sur l'ensemble des puits, ce qui donne les deux éléments de l'expression A. l. l. b, qui peuvent être considérés respecti- vement comme une sommation par ITEM, et un état du stock par ITEM. Il en résulte une demande apparente.

Selon un autre aspect de l'invention, il est ajouté un autre système de cumul illustré en 54 sur la figure 6, et qui permettra par exemple une visualisation 56 pour l'opérateur, comme on le verra également. Ce système peut utiliser aussi un état des confirmations de réservations ou commandes, tel qu'exprimé en A. l. l. e.

Le fonctionnement du mécanisme 54 s'appuie avantageusement sur une programmation par objets, utilisant les objets définis en A. 1.2. Dans le tableau A. 1.2, le délai DA est défini de la manière suivante : si on doit approvisionner le produit à la. date J, sa demande ferme doit être confirmée au plus tard à J-DA.

Ce mécanisme sera décrit ici pour un produit donné"PROD_i", mais devra bien entendu être répété pour chaque type de produit nécessaire à un puits, par exemple les trois classes de tubes TO, T1 et T2 décrites à propos de la figure 1.

Sur la figure 7, pour un produit PROD_i illustré en 600, on effectue tout d'abord trois opérations de tri (exprimées sur la figure par l'instruction de tri habituelle"SORT") : - les instances trient les produits (objet"ITEM") d'après la somme des dates DP et DI, à savoir la date prévue de démar- rage du puits, et le délai entre la date de démarrage du puits et le besoin du produit sur la plate-forme (tous les délais sont exprimés en jours dans cet exemple) ; - l'étape 604 trie les produits en stock (objets"STOCK") par leur date d'entrée en stock JS ; - l'opération 606 trie les achats, d'après leur date prévue d'approvisionnement JA.

Bien entendu, les trois opérations 602,604 et 606 font à chaque fois intervenir des quantités, respectivement QI, QS et QA.

L'invention peut être mise en oeuvre à l'aide d'une ou plusieurs tables (informatiques), logiques ou physiques.

Les spécialistes de la programmation objet comprendront qu'un objet ITEM est une instance d'une classe ITEM, ayant les propriétés définies dans l'annexe A. 1.2., avec à chaque fois une valeur correspondante de la propriété, par exemple une quantité QI et un délai DI, s'agissant de l'objet ITEM.

On remarquera aussi que le tri des objets ITEM fait interve nir une relation entre 1'ITEM et le puits Pi auquel il est rattaché, puisqu'il faut faire la somme des dates DP et DI.

Après ces tris, l'invention prévoit d'effectuer un cumul à partir d'un instant initial to.

Les cumuls s'effectuent sur une séquence de tranche de temps, partant de l'instant to, et de durée choisie. Dans l'exemple décrit, l'unité de mesure de temps est le jour, et une tranche de temps peut être égale à une journée, ou un multiple d'une journée, si on lé souhaite. L'opération 610 consiste à mettre à zéro un indice de tranche de temps dans la séquence, noté p.

A l'étape 612, on effectue une sommation (612a) depuis la tranche de temps 0 jusqu'à la tranche de temps p de la somme des stocks et des achats dans chaque tranche de temps, ce qui fournit une quantité Rp. De même, on fait la somme (612b) depuis la tranche de temps initiale jusqu'à la tranche de temps p des valeurs ITEM i pendant chacune de ces tranches de temps, ce qui donne un résultat Bp.

L'opération 614 incrémente p. Si l'on n'a pas atteint en 616 une valeur maximale, qui correspond à une projection future d'étendue choisie, au besoin évolutive, on réitère les opérations 612 et 614. Lorsque la valeur maximale de p est obtenue, on procède à l'exploitation du résultat en 618.

La forme donnée à l'opération 612 est purement illustrative.

En fait, on opérera plutôt itérativement : on calcule d'abord les résultats Ro et Bo pour la tranche de temps 0, puis au passage suivant dans la boucle, on calcule R1 et B1 en ajoutant respectivement à Ro et Bo ce qui correspond à la tranche de temps 1, et ainsi de suite.

On note maintenant. B l'ensemble des résultats Bp pour p = 0 à Pmaxt et R l'ensemble des ressources Rp pour p = 0 à Pmax* Ces quantités peuvent être visualisées en fonction du temps comme indiqué sur la figure 8. Les risques de rupture d'approvisionnement apparaissent au moment où la courbe des besoins B dépasse la courbe R de stocks plus réservations (stocks + commandes faites ou programmées), par exemple entre les instants J1 et J2, comme illustré par des hachures. Ces conditions peuvent être évaluées informatiquement à l'étape 618.

Ce qui précède peut être mis en oeuvre en utilisant des classes-objet supplémentaires, en particulier une classe- objet (ELEMENT TABLE) pour un élément de table comprenant une quantité (Q) et un temps (t). On peut prévoir une classe supplémentaire pour un tableau ("ARRAY"), nommé par exemple SEQUENCE, et comprenant un ELEMENT TABLE pour chaque tranche de temps dans la séquence. Le nombre de tranches de temps peut être rendu variable dynamiquement.

Les résultats peuvent être mis à disposition de l'utilisateur sous toute autre forme, par exemple sous la forme du tableau illustré sur la figure 9, qui comporte plus d'informations.

Dans un mode de réalisation, la Demanderesse utilise une pluralité de vues-écran différentes d'une même table regrou pant toutes les informations issues du traitement.

La mise en évidence des manques doit inciter le gestionnaire (la personne représentant le fournisseur chez le client) à négocier des actions à mener : demande d'approvisionnement auprès des fournisseurs, modification d'une demande prévue :

quantités, dates, ou proposer des aménagements. Une généra- tion automatique de commande est envisageable. De même, on peut ajouter un accusé de réception de mise en stock, pour les produits neufs, ou de retours de produits reconditionnés à neuf.

L'ensemble des opérations décrites ci-dessus peuvent être effectuées dans l'ordinateur CSc présent sur le site client.

Elles utilisent le planning local de production Pcl, en suivant les variations locales de production Dtcl. Ces opérations constituent ce que l'on appelle un ordonnancement, qui peut être réalisé par le client lui-même, par l'un des fournisseurs, ou par un tiers. Il est estimé actuellement préférable que l'ordonnancement soit dirigé par le fournis- seur principal, ou l'un d'entre eux. Par"fournisseur principal", on entend celui dont les produits sont les plus importants pour le client, par exemple en termes de critici- té, et/ou de volumes, et/ou de délai d'approvisionnement, notamment. Le fournisseur principal peut être aussi celui qui est le mieux placé pour gérer les besoins du client vis-à-vis d'autres fournisseurs.

La liaison avec un ordinateur CSf placé sur un site fournis seur permet de faire évoluer immédiatement le planning de production fournisseurs Pfo, et aussi de suivre également les variations locales de production DTfo, éventuellement.

Bien entendu, les enseignements de la présente invention peuvent également être mis en oeuvre sur le site du fournis seur, optionnellement vis-à-vis de ses propres fournisseurs.

Le fait de travailler en réseau permet également à l'application d'accéder à d'autres bases de données, si besoin est, ou à d'autres applications disponibles sur le réseau, et ce de façon totalement transparente pour l'utilisateur.

Fonctionnellement, l'invention offre un système informatique de suivi d'approvisionnement en flux tendu entre fournisseur

et client, comprenant un module de suivi (50, 52) capable d'entretenir en mémoire un état daté de besoins en produits (Ii, ti), associé à un ou des projets (Pi), en même temps qu'un état des stocks (Sj, t) et des achats (Ak, tk) de ces produits. Ce module de suivi comprend un module pilote (54), comportant : - un module de besoins (612a) capable, pour chaque type de produit, d'. établir. une première table, associée à une séquence de tranches de temps, ayant une origine de temps choisie, cette première table associant à chaque tranche de temps un premier cumul des besoins (Bp), depuis l'origine de temps jusqu'à la tranche de temps concernée, - un module de ressources (612b), capable, pour chaque type de produit, d'établir une seconde table, associée à la séquence de tranches de temps, cette seconde table associant à chaque tranche de temps un second cumul (Rp) de stocks plus achats, depuis l'origine de temps jusqu'à la tranche de temps concernée, les achats étant décalés temporellement en fonction d'un délai (DA ; DI), et - un comparateur (618) pour rechercher les temps auxquels les seconds cumuls deviennent inférieurs aux premiers, comme indicateurs d'un risque de rupture d'approvisionnement.

Informatiquement, ce qui précède invoque deux tables "logiques", à savoir une table des besoins et une table des ressources (elle-même décomposable en une table des stocks et une table des achats. ). En pratique, on pourra utiliser une seule table"physique"réunissant les deux tables ci- dessus (ou plus), l'appartenance à l'une des tables étant par exemple indiquée par un champ dédié à cet effet.

L'invention vise également un procédé informatique de suivi d'approvisionnement en flux tendu entre fournisseur et client, dans lequel, sur un site client, chaque projet (Pi) est associé à un état daté de besoins (Ii, ti) en produits, en même temps qu'il est tenu un état des stocks (SD, tj) et des achats (Ak, tk) de ces produits. Ce procédé comprend avanta- geusement les étapes suivantes :

b. établir (50) une liste de types de produits (Ii) inter- venant dans un ou plusieurs projets (Pi), b. pour chaque type de produit amont (Ii), établir (612), dans au moins une table (Bp, Rp), et pour une séquence de tranches de temps, ayant une origine de temps choi- sie, * pour chaque tranche de temps, un premier cumul, depuis l'origine de temps jusqu'à la tranche de temps concernée, d'une première quantité (Bp) reliée aux besoins datés (Ii, ti) sur le site client, * pour chaque tranche de temps, un second cumul, depuis l'origine de temps jusqu'à la tranche de temps concernée, d'une seconde quantité (Rp) reliée aux stocks (Sj, tj) et aux achats (Ak, tk), les achats étant décalés temporellement en fonction d'un délai (DA, DI), et c. rechercher (618) les temps auxquels les seconds cumuls deviennent inférieurs aux premiers, comme indicateurs d'un risque de rupture d'approvisionnement.

En termes de traitement informatique, il est intéressant d'utiliser une unique fonction de cumul. L'invention peut donc être vue également comme un système informatique de suivi d'approvisionnement en flux tendu entre fournisseur et client, comprenant un module de suivi (50,52) capable d'entretenir en mémoire un état daté de besoins en produits (Ii, ti), associé à un ou des projets (Pi), en même temps qu'un état des stocks (Sj, tj) et des achats (Ak, tk) de ces produits. Ce module de suivi comprend : - un module de cumul (612), capable de recevoir pour paramè tres la désignation d'un type de produit, d'un mode, ainsi que d'une origine de temps, et d'établir, pour le type de produit désigné, une table associant à des tranches de temps successives un cumul de quantités du produit, définies par le mode, chaque cumul allant depuis l'origine de temps jusqu'à la tranche de temps concernée, et - un module pilote (54), agencé pour :

* appeler le module de cumul (612) avec un type de produit, et un mode comprenant le cumul besoins sur le site client, ce qui fournit une première table, * appeler le module de cumul (612) avec le même type de produit, et un mode comprenant le cumul stocks plus livraisons, ce qui fournit une seconde table, et * rechercher (618) les temps auxquels les cumuls de la seconde table deviennent inférieurs à ceux de la pre- mière table, comme indicateurs d'un risque de rupture d'approvisionnement.

Les opérations ci-dessus sont réitérées à une cadence convenable compte-tenu de la vitesse d'évolution de la situation. De préférence, elle sont également réitérées en présence d'événements déterminés, qui peuvent comprendre l'un au moins des événements du groupe comprenant : modification d'une date de projet par le client, modification d'une date de disponibilité par le client, modification d'un délai d' approvisionnement par le fournisseur, modification des quantités de produit à approvisionner, passage d'une commande du client au fournisseur, confirmation d'une commande, réservation de produit sur stock, livraison d'un produit.

Le procédé peut comprendre en outre la prise d'une commande, au plus tard à une date sensiblement égale à la date de démarrage du projet concerné (DP), augmentée d'un délai de disponibilité (DI), et diminuée d'un délai d'approvisionnement (DA).

On a vu que la présente invention travaille par cumul. Le problème d'un cumul est qu'il tend normalement à augmenter indéfiniment. Selon un autre aspect de l'invention, les informations sont"re-synchronisées"périodiquement, par élimination des données du passé, de façon à limiter leur encombrement, ainsi que les temps de traitement.

Avantageusement, cette re-synchronisation peut s'effectuer sous la forme d'une remise à zéro des cumuls, chaque fois que les besoins correspondent sensiblement aux ressources, et, le

cas échéant, dans une mesure compatible avec la nécessité de conserver, sous forme active (autre qu'archivée), une vue "historique"de l'exploitation. Au moment de la re-synchro- nisation, l'écart résiduel entre les besoins et les ressour- ces peut être re-qualifié comme un stock.

Dans l'exemple décrit, on a mentionné à titre d'exemple des tubes de forage. L'invention peut s'étendre à diverses sortes d'autres produits utiles lors des forages (ou"composants des puits"), notamment ceux connectés aux tubes : - les tubes courts (dits"pup joints"), destinés notamment à ajuster la longueur de la colonne de tubages ("tubings") en fonction de la longueur réelle descendue.

- les raccords filetés ("cross-over") utilisés in situ. ainsi que des accessoires, plus complexes, relevant en général de fournisseurs spécialisés, autres que les tubistes, comme : - vannes de sécurité ("safety valves") - support de cuvelage ("casing hanger") - sabot de cimentation ("cement shoe") - support de tubes horizontaux ("liner hanger").

Sur un autre plan, il peut être intéressant de lier certains des composants des puits entre eux, dans le temps et dans les quantités, notamment pour des accessoires. Un exemple en est illustré sur la figure 10. Il est courant de monter un accessoire de tube ("SUPERACC"), comprenant deux tubes courts ("PJ"pour"pup joints") associés à une vanne de sécurité ("SV"). Informatiquement, on a alors : - une classe objet"vanne de sécurité"SV, particularisée par des attributs d'objet qui peuvent comprendre un identifiant SVID, un temps de montage SVDLY, et une propriété SVLINK, sur laquelle on reviendra.

- une classe objet"tube court"PJ, particularisée par des attributs d'objet qui peuvent comprendre un identifiant PJ-ID, et un temps de montage PJDLY.

On peut définir à partir de là un objet étendu"accessoire de tube"SUPERACC qui comprend une instance de la classe objet

SV, et deux instances de la classe objet PJ, ce qui définit complètement l'accessoire.

Ceci peut être obtenu par le lien SVLINK, qui est par exemple une méthode, notée alors SV_LINK (), activable pour désigner automatiquement, par exemple par leur (s) identi- fiants PJID, les deux tubes courts qui s'accordent avec l'identifiant SVID de la vanne de sécurité dont on part pour créer l'accessoire SUPERACC. La même méthode peut aussi faire la synthèse des délais d'implantation SV DLY et PJDLY, pour définir directement le délai d'anticipation SUPER- ACCDLY, à prévoir pour l'accessoire SUPERACC. Cet exemple simple montre comment on peut avoir des composants de puits liés entre eux, dans le temps (les délais) et dans les quantités (deux PJ pour un SV). Il est aisément généralisable à des cas plus complexes.

Par ailleurs, la présente invention n'est en aucune manière limitée à l'application aux sites de forage, mentionnée dans cette description détaillée. Cette application est particu- lièrement marquante, en ce sens qu'elle fait intervenir des produits très différents en grands volumes, ayant des temps de fabrication longs, nécessitant des ressources de fabrica tion dispersées, et difficiles à transporter, avec de surcroît des accessoires, le tout pour une application clients qui est lourde, importante et évolutive par nature.

A côté de cela, les produits tubulaires livrés sont utilisés tels quels, ou peu modifiés. Pour des tubes, on ne réalise en général que des opérations assez simples, sur le site client : filetage du tube in situ, ou adaptation de tubes en des produits dérivés, comme les tubes courts précités, qui peuvent être dimensionnés sur place. Ces opérations sont d'ailleurs généralement effectuées par le fournisseur, ou un tiers, sur le site client.

L'invention peut bien entendu s'appliquer a priori à d'autres domaines techniques, où des produits quasi-finis et de manipulation/transport non immédiats, en particulier des

tubes, sont largement utilisés, avec des contraintes de temps.

Cependant, l'invention reste encore applicable à de nombreux autres domaines, qui possèdent tout ou partie des contraintes précitées, quelle que soit l'échelle de temps de l'évolution.

Le paramètre critique apparait être en fait le rapport entre le coût d'un éventuel temps perdu et l'investissement.

La présente invention vise également le code logiciel qu'elle fait intervenir au niveau du procédé ou du système, tout particulièrement lorsqu'il est mis à disposition sur tout support lisible sur un ordinateur. L'expression"support lisible par ordinateur"couvre un support de stockage, par exemple magnétique ou optique, aussi bien qu'un moyen de transmission, tel qu'un signal numérique ou analogique.

Annexe 1 A.1.0 - notations - Puits: Pi - état date des produits (Item): (Ii, ti) - état date des stocks : (Sj, tj) - état daté des Achats : (Ak, tk) A. 1. 1-éléments de base A. l 1. a { Pi, Ii, ti} * A.1.1.b Ii = f ( Pi, t) * A. 1. l. c { Sj, tj} * A.1.1.d {Ii, ti} # {Sj, tj} * A.1.1.e { Ik, tk } Al. 2-Objets (logiciels) et leurs propriétés OBJETS PROPRIÉTÉS (simplifiées) PUITS Désignation DP Date prévue de démarrage statut {prévu, précisé, confirmé, en cours, clos} PRODUIT Désignation DA Délai maximal d'approvisionnement Fournisseur statut {produit, accessoire,..} OBJETS PROPRIÉTÉS (simplifiées) ITEM QI Quantité (mètres de tube) DI Délai entre date de démarrage du puits et besoin du produit sur la plate forme (en jours) Référence au puits Référence au produit N° d'ordre dans la descente dans le puits Observations STOCK QS Quantité en stock JS Date d'entrée en stock Référence entrée en stock (camion, retour,...) Date de sortie du stock Date de dernière inspection Référence tube (repère usine) Lieu de stockage (loge) ACHAT QA Quantité à approvisionner JA Date prévue d'approvisionnement (sortie usine) Délai moyen de transport (usine-stock) No commande interne ? commande fournisseur statut {consultation, réservation, commande}