FR 2884337 A1 20061013 FR 0503558 A 20050411 3Netl.FRD.wpd DISPOSITIF PERFECTIONNÉ DE TRAITEMENT DE DONNÉES POUR LA GESTION DE LA RELATION AVEC DES TIERS L'invention concerne les outils généralistes de traitement de données de gestion, tels que les progiciels de gestion intégrée, ainsi que leurs modules de gestion de la relation avec des tiers. On entend ici par "tiers" toute personne physique ou morale avec laquelle on a établi une relation. Il peut donc s'agir d'un client, d'un fournisseur, d'un partenaire ou d'un prospect. Les outils précités reposent sur un système informatique, muni d'un gestionnaire de tables en base de données. Celui-ci peut s'articuler sur une gestion directe des tables, effectuée par exemple par codage dans un environnement de développement rapide, tel que celui vendu par la société Microsoft sous la dénomination Access . La constitution de bases de données peut se faire aussi de façon plus détachée du code, notamment sous le langage SQL, à l'aide d'un serveur de bases de données relationnelles, comme ceux vendus par la société ORACLE des Etats-Unis. Les outils ainsi établis sont généralistes, en ce sens que leurs utilisateurs (ou entités utilisatrices) peuvent les adapter aux besoins liés à leurs activités. La structure généraliste de tels outils comprend des fichiers (physiques ou logiques), définissant des tables de base comportant des enregistrements. A priori ce type d'outil comprend: une ou des tables de personnes, physiques ou morales, une ou des tables d'affaires, représentant une activité entre une personne et l'entité utilisatrice, une ou des tables d'événements ou actions ou encore interventions, en principe lié(e)s chacun(e) à une affaire, et entre ces tables de base, des interconnexions sélectives ou relations. Il s'y ajoute une interface utilisateur permettant à l'entité utilisatrice (ou "utilisateur") d'interagir avec les tables de base pour le suivi de la gestion de ses activités. Ce suivi comprend éventuellement un paramétrage des tables de base, et de leurs relations, et bien entendu leur chargement avec les données propres à l'entité utilisatrice (lesquelles constituent les enregistrements), ainsi que le maintien à jour de ces données. Ainsi, l'utilisateur peut d'une part lier une affaire à une ou plusieurs personnes, à des titres définis. Il peut d'autre part, éventuellement, lier une affaire à un ou plusieurs événements (ou actions ou encore interventions) qui se déroulent dans le cadre de cette affaire. Ces outils sont le plus souvent multi-utilisateurs (entités), et/ou multiorientations. L'expression "multi-orientations" signifie que l'outil peut servir d'un côté pour des clients prospects, d'un autre pour des clients avérés, d'un autre encore pour des partenaires, et aussi pour des fournisseurs. Suivant l'organisation interne de l'outil, il en découle notamment une forte redondance, au niveau des personnes: le plus logique est de multiplier les tables de personnes, à raison du nombre d'orientions différentes données à l'outil; si l'on conserve une seule table de personnes, il faut alors en compliquer assez considérablement la structure, et elle va aussi 2 0 contenir rapidement de nombreuses lignes redondantes. Les solutions actuelles ne sont donc pas techniquement satisfaisantes. La présente invention a pour objet d'améliorer la situation. Elle propose à cet effet un dispositif de traitement de données, comprenant un système informatique muni d'un code de programme capable, d'une part, de maintenir des tables de base comportant des enregistrements, dont une table de personnes et une table d'affaires, ainsi que d'établir des liens entre ces tables, et d'autre part, de procurer une interface utilisateur, permettant d'interagir avec les tables de base pour y créer ou modifier des enregistrements, afin d'assurer le suivi sélectif d'une pluralité d'activités. Ce dispositif se caractérise par le fait: - qu'il comprend une table additionnelle dite de "dossiers", dont chaque enregistrement comporte un premier champ qui forme un pointeur vers un champ, formant clé, de la table de personnes, et un deuxième champ, formant clé, que ladite table d'affaires comprend, pour chaque enregistrement, un premier champ formant pointeur vers le deuxième champ, formant clé, de la table de dossiers, et - que l'interface utilisateur est agencée pour imposer (à l'utilisateur) la création d'un enregistrement dans la table de dossiers à chaque création d'un enregistrement dans la table d'affaires, le lien entre un enregistrement de la table d'affaires et un enregistrement de la table de personnes se faisant alors par l'intermédiaire de la table de dossiers. Le dispositif selon l'invention peut comporter des caractéristiques complémentaires qui peuvent être prises séparément ou en combinaison, et notamment: son code de programme peut comprendre un gestionnaire de tables en base de données, ainsi qu'éventuellement un logiciel d'application articulé sur le gestionnaire de tables en 15 base de données; une autre table de base additionnelle dite "d'interventions". Dans ce cas, au sein de la table d'affaires chaque enregistrement comprend un deuxième champ formant clé, et au sein de la table d'interventions chaque enregistrement comprend un premier champ formant pointeur (directement ou indirectement) vers le deuxième champ, formant clé, de la table d'affaires; chaque enregistrement de la table d'affaires peut comprendre un troisième champ, formant clé. Dans ce cas, on prévoit une autre table additionnelle dite "de réservoir d'affaires" dont chaque enregistrement comporte un deuxième champ formant clé primaire et vers lequel pointe le troisième champ de la table d'affaires; chaque enregistrement de la table de dossiers peut comprendre un troisième champ, formant clé. Dans ce cas, on prévoit une autre table additionnelle dite "de réservoir de dossiers" dont chaque enregistrement comporte un deuxième champ formant clé primaire et vers lequel pointe le troisième champ de la table de dossiers; - chaque enregistrement de la table de réservoir d'affaires peut comprendre un premier 3 0 champ, formant un pointeur vers le deuxième champ, formant clé primaire, de la table de réservoir de dossiers; - une autre table additionnelle dite "de demandeurs" dont chaque enregistrement comporte un champ formant clé primaire. Dans ce cas, l'une au moins des tables de réservoir de dossiers, table de dossier, table de réservoir d'affaires et table d'affaires comprend un champ, formant un pointeur vers le champ, formant clé primaire, de la table de demandeurs; chaque enregistrement de la table de réservoir de dossiers peut comprendre un premier champ formant le pointeur vers le champ, formant clé primaire, de la table de demandeurs; - une autre table de base additionnelle dite "de portage d'informations" dont chaque enregistrement comporte un premier champ, formant un pointeur vers le champ qui forme clé de la table de demandeurs, et/ou un deuxième champ, formant un pointeur vers le champ qui forme clé de la table de personnes. 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: la figure 1 illustre de façon très schématique et fonctionnelle un exemple de réalisation d'un dispositif de traitement de données selon l'invention, implanté dans un ordinateur disposant d'un environnement de développement rapide, la figure 2 illustre de façon schématique un exemple de relations entre des tables de base d'un dispositif de traitement de données selon l'invention, la figure 3 illustre de façon très schématique un exemple de points d'entrée aux tables de 2 0 base du dispositif selon l'invention, dans une application à la gestion des relations avec des tiers, la figure 4 est une copie d'écran matérialisant une partie d'un portefeuille de tiers (clientsfournisseurs-partenaires-prospects), la figure 5 est une copie d'écran matérialisant un exemple de recherche de fiches au moyen du champ "MEU" dans le portefeuille de la figure 4, la figure 6 est une copie d'écran matérialisant la fiche correspondant à l'un des clients ("MEUBLE RUSTIQUE") appartenant à la liste extraite du portefeuille de la figure 5, la figure 7 est une copie d'écran matérialisant les dossiers associés au client de la fiche illustrée sur la figure 6, 3 0 la figure 8 est une copie d'écran matérialisant l'ensemble des enregistrements d'interventions constituant l'historique de la fiche du client de la figure 6, la figure 9 est une copie d'écran matérialisant l'ensemble des renseignements sur les contacts du client de la figure 6, pour son dossier "CHAMBRE/ADULTE", et la figure 10 est une copie d'écran matérialisant un exemple d'intervention relative au client "REVOL PORCELAINE" du portefeuille de la figure 4. La description qui suit est complétée par les annexes suivantes: l'annexe Al énonce des structures d'un certain nombre de tables de base utilisables dans un exemple de réalisation de la présente invention, et l'annexe A2 illustre pour le même exemple la définition des liaisons entre les tables de 10 base et les contraintes qui leur sont appliquées. Ces Annexes sont mises à part dans un but de clarification, et pour faciliter les renvois. Elles sont parties intégrante de la description, et pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. Ceci s'applique également en tous points aux dessins. La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa 2 0 description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits. On se réfère tout d'abord à la figure 1 pour décrire un exemple de réalisation d'un dispositif de traitement de données D selon l'invention. On considère dans ce qui suit que le dispositif D est un outil dédié à la gestion des relations avec des tiers (clients, fournisseurs, partenaires et/ou prospects). Mais, le dispositif D pourrait ne constituer qu'un module de gestion de la relation avec des tiers d'un progiciel de gestion intégrée. Par ailleurs, le dispositif D pourrait être un outil dédié à la gestion de ressources et de salariés. Dans l'exemple illustré sur la figure 1, le dispositif D est implanté dans un ordinateur (ou un serveur) PC. Il se présente sous la forme d'un système informatique muni d'un code de programme définissant un module de gestion MG, capable de maintenir des tables de base Ti stockées dans une mémoire M et d'établir des liens (ou liaisons) entre ces tables de base Ti, ainsi qu'une interface utilisateur lU, permettant à un utilisateur d'interagir avec les tables de base Ti pour y créer ou modifier des enregistrements de données, afin d'assurer le suivi sélectif d'une pluralité d'activités ou d'affaires. Le mot "mémoire" ne doit pas être compris dans une définition restrictive. Il vise en effet tout moyen de mémorisation de données, et notamment les bases de données. Le dispositif D peut également comprendre un logiciel d'application LA articulé sur son module de gestion MG. Un tel logiciel d'application LA est un logiciel externe qui peut par exemple être dédié à la gestion comptable, la gestion de production ou la gestion de temps. Dans l'exemple illustré sur les figures 1 et 2, la mémoire M comporte huit (i=l à 8) tables de base Ti. Mais, comme on le verra plus loin, la mémoire M peut comporter un nombre de tables de base différent de huit, et au moins égal à trois. Plus précisément, la mémoire M stocke au moins une table de base dite "table de personnes" (ou table de fiches ) Tl (également référencée "DbPorteFiche" sur la figure 2), une table de base dite "table de dossiers" T2 (également référencée "DbPorteDoss" sur la figure 2), et une table de base dite "table d'affaires" T3 (également référencée "DbDossAff' sur la figure 2). On entend ici par "table de personnes" Ti une table contenant des données d'information relatives à des tiers (personnes physiques ou morales), constituant des clients, fournisseurs, partenaires et/ou prospects. Parfois dans ce qui suit, un tiers (ou personne) de la table Tl est également appelé portefeuille. Ces données d'information portent par exemple sur les numéros d'enregistrement administratifs et le chiffre d'affaire de la personne morale ou physique, notamment. Par ailleurs, on entend ici par "table de dossiers" T2 une table contenant des données 3 0 d' information relatives à des activités stratégiques ou des branches d'un tiers disposant d'un enregistrement dans la table de personnes Tl. Cette table de dossiers T2 contient des enregistrements relatifs à des dossiers qui peuvent être éventuellement regroupés en classes ou variétés différentes de dossiers, comme on le verra plus loin. Un exemple non limitatif de format de table de dossiers T2 est donné dans l'annexe A1.2. En outre, on entend ici par "table d'affaires" T3 une table contenant des données d'informa- tion relatives à des échanges commerciaux, des actions ou des litiges relatifs à un dossier (d'un tiers) disposant d'un enregistrement dans la table de dossiers T2. Cette table d'affaires T3 contient des enregistrements relatifs à des affaires qui peuvent être éventuellement regroupées en classes ou variétés différentes d'affaires, comme on le verra plus loin. Un exemple non limitatif de format de table d'affaires T3 est donné dans l'annexe A1.3. Les tables de base Ti sont préférentiellement agencées sous la forme de bases de données. Selon l'invention et comme illustré sur la figure 2 et dans l'annexe A1.1, chaque enregistrement de la table de personnes T1 comporte un champ formant clé (ici appelé 15 "POCLEUNIKD"). Egalement selon l'invention et comme illustré sur la figure 2 et dans l'annexe A1.2, chaque enregistrement de la table de dossiers T2 comporte un (premier) champ (ici appelé "POCLEUNIKD") qui forme un pointeur vers le champ formant clé (ici appelé "POCLEU- 2 0 NIKD") de la table de personnes T 1, ainsi qu'un (deuxième) champ formant clé primaire (ici appelé "DFCLEUNIKD"). Toujours selon l'invention et comme illustré sur la figure 2 et dans l'annexe A1.3, chaque enregistrement de la table d'affaires T3 comprend un (premier) champ (ici appelé "DF- 2 5 CLEUNIKD") qui forme un pointeur vers le (deuxième) champ formant clé DFCLEUNIKD de la table de dossiers T2, ainsi qu'un (deuxième) champ (ici appelé "DACLEUNIKD") formant clé primaire. On entend ici par "clé" une clé unique primaire (champ en majuscule souligné), lorsqu'elle 30 désigne une table, ou une clé standard (champ en majuscule, non souligné), lorsqu'elle forme un pointeur vers une clé primaire d'une autre table. Egalement selon l'invention, l'interface utilisateur IU est chargée d'imposer à l'utilisateur la création d'un enregistrement dans la table de dossiers T2 chaque fois qu'un enregistre-ment est créé dans la table d'affaires T3. Ainsi, et comme cela est illustré sur la figure 2 (qui matérialise les liens entre huit tables Ti à T8 et pas seulement entre les trois tables précitées Ti à T3), le lien entre un enregistrement de la table d'affaires T3 et un enregistrement de la table de personnes Tl se fait désormais par l'intermédiaire de la table de dossiers T2. Cela permet d'obtenir un découpage plus précis des données qui offre une meilleure lisibilité du fichier et/ou des analyses par secteur. En outre, cela permet un suivi plus organisé. Il est important de noter que les liaisons entre la table de personnes Ti et la table de dossiers T2, d'une part, et la table de dossiers T2 et la table d'affaires T3, d'autre part, imposent des contraintes. Des exemples non limitatifs de telles contraintes, correspondant aux formats des tables Tl à T3 donnés dans les annexes A1.1 à A1.3, sont fournis dans les annexes A2.1 et A2.2. Le module de gestion MG, également appelé gestionnaire de tables en base de données, est préférentiellement chargé d'assurer une gestion directe des tables Ti. Cette gestion directe se fait par exemple par codage dans un environnement de développement rapide ED (voir figure 1), implanté dans l'ordinateur PC. Cet environnement de développement rapide ED 2 0 peut être par exemple celui qui est vendu en France par la société PC soft sous la dénomination WinDev . Mais, d'autres codages utilisant d'autres langages peuvent être utilisés, et notamment Delphi, C++, Access. En variante, la constitution des tables Ti sous la forme de bases de données pourrait 2 5 également se faire de façon plus détachée du code, notamment sous le langage SQL, à l'aide d'un serveur de bases de données relationnelles, par exemple du type de ceux vendus par la société ORACLE. Les interrogations peuvent notamment se faire au moyen d'un langage naturel, en particulier pour ce qui concerne les requêtes en langage SQL. On peut également échanger les données en réseau, par exemple via le réseau Internet, ou bien en mode 3 0 client/serveur. Comme cela apparaît dans l'exemple illustré sur la figure 2, on peut adjoindre une ou plusieurs autres tables de base aux trois tables Ti à T3 présentées ci-avant. Par exemple, on peut adjoindre une table de base dite "d'interventions" T4 (également référencée "Dbinterven" sur la figure 2), comportant des enregistrements contenant chacun des données d'informations relatives à tout type d'événement ou d'intervention effectué(e) dans le cadre d'une affaire (de la table d'affaires T3) d'un dossier (de la table de dossiers T2) d'un tiers ou personne (de la table de personnes Tl). Un exemple non limitatif de format de table d'interventions T4 est donné dans l'annexe A1.4. Chaque enregistrement de la table d'interventions T4 comprend un (premier) champ (ici appelé "DACLEUNIKD") qui forme un pointeur vers le (deuxième) champ formant clé DACLEUNIKD de la table d'affaires T3, et un (deuxième) champ (appelé "IOCLEUNIKD") formant clé primaire. Les liaisons entre la table d'affaires T3 et la table d'interventions T4 imposent des contraintes. Des exemples non limitatifs de telles contraintes, correspondant aux formats des tables T3 et T4 donnés dans les annexes A1.3 et A1.4, sont fournis dans l'annexe A2.3. Lorsque la table d'affaires T3 est subdivisée en classes ou variétés d'affaires, on peut prévoir une autre table de base additionnelle dite table de réservoir d'affaires T5 (également référencée "DbAffaire" sur la figure 2). Cette table de réservoir d'affaires T5 contient des enregistrements de données d'information relatives à des classes ou variétés différentes d'affaires de la table d'affaires T3. Ces données d'information portent par exemple sur le nom d'un responsable d'affaires et sur un type d'affaire ("intitulé), notamment. Chaque enregistrement de cette table de réservoir d'affaires T5 comporte un (premier) 2 5 champ (ici appelé DOCLEUNIKD) qui forme un pointeur vers un deuxième champ DOCLEUNIKD sur lequel on reviendra plus loin, ainsi qu'un (deuxième) champ (ici appelé "AFCLEUNIKD") formant clé primaire et vers lequel pointe un (troisième) champ AFCLEUNIKD de la table d'affaires T3. Un exemple non limitatif de format de table de réservoir d'affaires T5 est donné dans l'annexe A1.5. Les liaisons entre la table de réservoir d'affaires T5 et la table d'affaires T3 imposent des contraintes. Des exemples non limitatifs de telles contraintes, correspondant aux formats des tables T5 et T3 donnés dans les annexes A1.5 et A.1.3, sont fournis dans l'annexe A2.4. En l'absence de classes ou de variétés d'affaires, cette table additionnelle T5 n'est pas utile. Lorsque la table de dossiers T2 est subdivisée en classes ou variétés d'affaires, on peut prévoir une autre table de base additionnelle dite table de réservoir de dossiers T6 (également référencée "DbDossier" sur la figure 2). Cette table de réservoir de dossiers T6 contient des enregistrements de données d'information relatives à des classes ou variétés différentes de dossiers de la table de dossiers T2. Ces données d'information portent par exemple sur le nom d'une classe de dossier, sa date d'ouverture ("début") et sa date de fermeture ("fin"), notamment. Chaque enregistrement de cette table de réservoir de dossiers T6 comporte un (deuxième) champ (ici appelé "DOCLEUNIKD") formant clé primaire et vers lequel pointe un (troisième) champ DOCLEUNIKD de la table de dossiers T2. Lorsque le dispositif D comprend une table de réservoir d'affaires T5, le (deuxième) champ 2 0 DOCLEUNIKD de celle-ci forme un pointeur vers le champ DOCLEUNIKD formant clé primaire de la table de réservoir de dossiers T6. On peut ainsi définir des réservoirs d'affaires associés chacun à un dossier. Un exemple non limitatif de format de table de réservoir de dossiers T6 est donné dans l'annexe A1.6. Les liaisons entre la table de réservoir de dossiers T6 et la table de dossiers T2, ainsi que celles entre la table de réservoir de dossiers T6 et la table de réservoir d'affaires T5 imposent des contraintes. Des exemples non limitatifs de telles contraintes, correspondant aux formats 3 0 des tables T2, T5 et T6 donnés dans les annexes A1.2, A.1.5 et A.1.6, sont fournis dans les annexes A2.5 et A.2.6. En l'absence de classes ou de variétés de dossiers, cette table additionnelle T6 n'est pas utile. Il est important de noter qu'en l'absence de la table de réservoir d'affaires T5 mais en présence de la table de réservoir de dossiers T6, le (troisième) champ de la table d'affaires T3 peut être le champ DOCLEUNIKD qui forme un pointeur vers le (deuxième) champ DOCLEUNIKD formant clé primaire de la table de réservoir de dossiers T6. Comme cela est également illustré sur la figure 2, chaque enregistrement de la table de réservoir de dossiers T6 peut également comprendre un (premier) champ (ici appelé DECLEUNIKD) qui forme un pointeur vers un (deuxième) champ DECLEUNIKD formant clé primaire d'une autre table de base additionnelle dite "table de demandeurs" T7 (également référencée "DbDemand" sur la figure 2). Cette table de demandeurs T7 contient des enregistrements relatifs àdes données d'informations assez simples sur les tiers (personnes physiques ou morales). Ces données d'information portent par exemple sur un nom, une adresse de correspondance, un numéro de téléphone, un numéro de télécopie (fax), une adresse électronique ("e-mail"), éventuelle-ment d'un siège social, notamment. Contrairement à la table de personnes Tl qui contient toutes les informations concernant les tiers et qui est principalement utilisée lors des recherches et des analyses, la table de demandeurs T7 est essentiellement utilisée pour offrir des vues différentes de la base de données. Ces vues différentes peuvent être notamment utiles à une entreprise effectuant des 2 5 missions, par exemple pour effectuer de la télé-prospection ou un suivi commercial. Chaque enregistrement de cette table de demandeurs T7 comporte un champ (ici appelé "DECLEUNIKD") formant clé primaire et vers lequel pointe un champ DECLEUNIKD d'une autre table. Dans l'exemple illustré sur la figure 2, c'est un (premier) champ 3 0 DECLEUNIKD de la table de réservoir de dossiers T6 qui pointe vers le champ DECLEUNIKD formant clé primaire de la table de demandeurs T7. Mais, il pourrait en être autrement. Ainsi, en l'absence de table de réservoir de dossiers T6, la table de dossiers T2 pourrait comporter un (troisième) champ DECLEUNIKD (au lieu de DOCLEUNIKD) pointant vers le champ DECLEUNIKD formant clé primaire de la table de demandeurs T7. En variante, la table de réservoir d'affaires T5 pourrait comporter un (deuxième) champ DECLEUNIKD (au lieu de DOCLEUNIKD) pointant vers le champ DECLEUNIKD formant clé primaire de la table de demandeurs T7. Par ailleurs, en l'absence de table de réservoir de dossiers T6 et de table de réservoir d'affaires T5, la table d'affaires T3 pourrait comporter un (troisième) champ DECLEUNIKD (au lieu de AFCLEUNIKD) pointant vers le champ DECLEUNIKD formant clé primaire de la table de demandeurs T7. Un exemple non limitatif de format de table de demandeurs T7 est donné dans l'annexe A1.7. La liaison entre la table de demandeurs T7 et la table de réservoir de dossiers T6 impose des contraintes. Des exemples non limitatifs de telles contraintes, correspondant aux formats des tables T6 et T7 donnés dans les annexes A1.6 et A.1.7, sont fournis dans l'annexe A2.7. Grâce à la table de réservoir de dossiers T6 et à la table de réservoir d'affaires T5, on peut établir des liens, d'une part, entre des enregistrements de la table de demandeurs T7 et des enregistrements de la table de dossiers T2, et d'autre part, entre des enregistrements de la table de demandeurs T7 et des enregistrements de la table d'affaires T3. Par exemple, cela peut permettre de savoir pour plusieurs demandeurs différents quelles sont leurs relations à un instant donné avec une entreprise de la table des demandeurs T7. Par exemple on peut apprendre que le demandeur al a ouvert un dossier pour l'entreprise B et qu'un rendez-vous a été pris du fait qu'elle constitue pour lui un client, que le demandeur a2 n'a ouvert qu'un dossier pour l'entreprise B et qu'elle ne constitue pour lui qu'un prospect, et que le demandeur a3 a ouvert un dossier de sondage pour l'entreprise B du fait qu'elle constitue pour lui un concurrent. Comme cela est également illustré sur la figure 2, on peut également prévoir une autre table 30 de base additionnelle dite "de portage d'informations" T8 (également référencée "DbPortelnf' sur la figure 2). Cette table de portage d'informations T8 contient des enregistrements relatifs, notamment, à des informations contenues dans la table de personnes Ti, comme par exemple la qualification d'un tiers (client, prospect), et/ou l'activité d'un tiers, et/ou son effectif, et/ou son existence, qui peuvent être vues sous un angle différent de la table de personnes Ti, grâce au couplage avec la table de demandeurs T7. Un exemple non limitatif de format de table de portage d'informations T8 est donné dans l'annexe A1.8. Les liaisons entre la table de demandeurs T7 et la table de portage d'informations T8 d'une part, et entre la table de personnes Ti et la table de portage d'informations T8 d'autre part, imposent des contraintes. Des exemples non limitatifs de telles contraintes, correspondant aux formats des tables T1, T7 et T8 donnés dans les annexes A.1.1, A1.7 et A. 1.8, sont fournis dans les annexes A2.8 et A.2.9. Comme cela est illustré sur la figure 3, les relations inter-tables illustrées sur la figure 2 offrent à l'utilisateur de nombreux points d'entrée à la base de données de gestion de la relation avec les tiers (clients, fournisseurs, partenaires ou prospects), agencée sous la forme de tables Ti dans la mémoire M. Comme illustré sur la copie d'écran de la figure 4, l'utilisateur peut par exemple afficher sur l'écran de son ordinateur PC, via l'interface utilisateur lU, un tableau de bord comportant l'ensemble des tiers (clients-fournisseurs-partenairesprospects) de son portefeuille (issu de la table Ti). L'utilisateur peut également, comme illustré sur la copie d'écran de la figure 5, afficher sur l'écran de son ordinateur PC, via l'interface utilisateur IU, une partie du portefeuille du tableau de bord de la figure 4. Dans cet exemple, la partie du portefeuille qui est sélectionnée est celle qui comprend les personnes morales ou physiques (tiers) dont les noms comportent les lettres "MEU". Il s'agit ici de MEUBLE RUSTIQUE,MEUBLES BONNARD et MEUBLES GRANGE. L'utilisateur peut également, comme illustré sur la copie d'écran de la figure 6, afficher sur l'écran de son ordinateur PC, via l'interface utilisateur IU, une fiche (de la table de personnes Ti). Dans cet exemple, la fiche extraite est celle concernant le tiers "MEUBLE RUSTIQUE". On peut notamment voir dans la partie inférieure de la copie d'écran que ce tiers est un client revendeur de meubles. L'utilisateur peut également, comme illustré sur la copie d'écran de la figure 7, afficher sur l'écran de son ordinateur PC, via l'interface utilisateur IU, les différents dossiers d'un tiers (de la table de personnes Ti) et les différentes affaires correspondant à ces dossiers. Dans cet exemple, le tiers sélectionné est "MEUBLE RUSTIQUE" qui dispose de deux dossiers "CHAMBRE/ADULTE" et "CHAMBRE/ENFANT" et dont les affaires sont toutes classées dans la classe d'affaires "GENERALE". L'utilisateur peut également, comme illustré sur la copie d'écran de la figure 8, afficher sur l'écran de son ordinateur PC, via l'interface utilisateur IU, l'historique d'une fiche d'un tiers (de la table de personnes Tl). Dans cet exemple, le tiers sélectionné est "MEUBLE RUSTIQUE". L'historique des interventions effectuées avec ce tiers porte ici sur ses deux dossiers "CHAMBRE/ADULTE" et "CHAMBRE/ENFANT". 2 0 L'utilisateur peut également, comme illustré sur la copie d'écran de la figure 9, afficher sur l'écran de son ordinateur PC, via l'interface utilisateur IU, des renseignements (ou informations) sur un tiers (de la table de personnes Tl). Dans cet exemple, le tiers sélectionné est "MEUBLE RUSTIQUE" et l'utilisateur recherche les informations concernant la personne à contacter chez le tiers pour ce qui concerne le dossier 2 5 "CHAMBRE/ADULTE". Il s'agit ici de "Mr BERTRAND". L'utilisateur peut également, comme illustré sur la copie d'écran de la figure 10, afficher sur l'écran de son ordinateur PC, via l'interface utilisateur IU, soit un ancien enregistrement d'intervention concernant un tiers (de la table de personnes Tl), soit une page de saisie 3 0 d'enregistrement d'intervention concernant un tiers (de la table de personnes Tl). Dans cet exemple, le tiers sélectionné est "REVOL PORCELAINE", et la personne à contacter n'est pas connue ("Mr NON CONNU"). On peut par ailleurs noter que l'intervention s'est faite sous la forme d'un appel téléphonique le 30 novembre 2004 ("30/11/2004"), à l'initiative du service commercial ("Service commercial") et sous un niveau d'urgence normal et un niveau de priorité normal. D'une manière générale, et comme cela est illustré sur la figure 3: le tableau de bord est lié à l'historique, aux interventions, aux fiches et aux renseignements, le portefeuille est lié aux dossiers, aux renseignements, aux fiches et à l'historique, l'historique est lié aux fiches, aux interventions et aux renseignements, les dossiers sont liés aux renseignements, aux interventions et à l'historique, les fiches sont liées aux renseignements, les interventions sont liées aux renseignements et aux fiches, les renseignements sont liés aux dossiers et affaires, et donc au portefeuille, le lien entre les renseignements et les interventions se fait par l'intermédiaire des affaires. Bien entendu, de très nombreuses autres possibilités peuvent être envisagées. Elles dépendent notamment du nombre de tables de base Ti utilisées et des champs que comportent leurs enregistrements. Le dispositif de traitement de données D, selon l'invention, et notamment son interface 2 0 utilisateur IU et son module de gestion MG, ainsi qu'éventuellement sa mémoire M, peuvent être réalisés sous la forme de circuits électroniques (ou "hardware"), de modules logiciels (ou informatiques ou encore codes de programme - "software"), ou d'une combinaison de circuits électroniques et de modules logiciels. Par conséquent, le dispositif de traitement de données D, selon l'invention, peut être implanté ou téléchargé dans un ordinateur. Cette implantation peut se faire sous toute forme, et notamment sous la forme d'une carte électronique ou d'un logiciel mis à disposition sous tout "medium" (ou support) lisible par ordinateur. L'expression "medium lisible par ordinateur" comprend les supports de stockage de données, magnétiques, optiques et/ou 3 0 électroniques, aussi bien qu'un support ou véhicule de transmission, comme un signal analogique ou numérique. L'invention ne se limite pas aux modes de réalisation de dispositif de traitement de données décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après. Annexe Al - Structures de tables Notes: - les clés uniques sont en majuscules, et se terminent en général par "CLEUNIKD" - la clé unique qui sert aussi de clé primaire de la table est en outre 5 soulignée. A1.1 DbPorteFiche: table de personnes (ou fiches) Champ Libellé champ Type Taille Clé Clé Sens Val. défaut POCLEUNIKD Pocleunikd Chaîne 21 UNIQ. Asc. NomFiche Nom Chaîne 60 Multi Asc. NumSiret Numéro siret Chaîne 20 Existeplus N'existe plus Entier non signé 1 octet Multi Asc. 0 CAEntre Chiffre d'affaire Réel 8 octets 0. 000000 CodeNaF CodeNaF Chaîne 6 PorCapital Capital Entier 4 octets 0 EFCLEUNIKD Taille Chaîne 21 UNIQ. CreeLe Crée le Date (aaaammjj) A1.2 - DbPorteDoss: table de dossiers Champ Libellé champ Type Taille Clé Clé Sens Val. défaut DFCLEUNIKD Dfcleunikd Chaîne 21 UNIQ. Asc. Commentaire Commentaire Mémo texte bInterv Intervenant Chaîne 10 POCLEUNIKD Encleunikd Chaîne 21 UNIQ. Asc. DOCLEUNIKD Docleunikd Chaîne 21 UNIQ. Asc. A1.3 - DbDossAff: table d'affaires Champ Libellé champ Type Taille Clé Clé Val.de'faut Sens DACLEUNIKD DACLEUNIKD Chaîne 21 UNIQ. Asc. AFCLEUNIKD AFCLEUNIKD Chaîne 21 UNIQ. Asc. DFCLEUNIKD DFCLEUNIKD Chaîne 21 UNIQ. Asc. Sclntitule Nom affaire Chaîne 25 bInterv Qui s'en occupe Chaîne 10 4 0 DateDeb Début Date (aaaammjj) DateFin Fin Date (aaaammjj) Affresultat Resultat Entier non signé 2 octets 0 Commentaire Commentaire Mémo texte A1.4 - DbInterven: table d'interventions Champ Libellé Type Taille Clé Clé Val. défaut champ Sens IOCLEUNIKD IOcleunikd Chaîne 21 UNIQ. Asc. IntDate Date Date (aaaammjj) Multi Asc. DACLEUNIKD DACLEUNIKD Chaîne 21 UNIQ. Asc. IntType Type Chaîne 150 Multi Asc. IntFait Intfait Entier non signé 1 octet Multi Asc. 0 bInterv Utilisateur Chaîne 10 Multi Asc. faisant l'action C1CLEUNIKD Clcleunikd Chaîne 21 UNIQ. Asc. Initat Qui à pris Chaîne 25 Multi Asc. Initative: Commercial, secréatire, ... IntHeure Heure Heure (hhmm) IntCommentaire Commentaire Mémo texte IntUrgence Niveau Entier 2 octets 0 d'urgence IntPriorite Priorité Entier non signé 1 octet 0 A1.5 - DbAffaire: table de réservoir d'affaires Champ Libellé champ Type Taille Clé Clé Sens VaL defaut AFCLEUNIKD AFCLEUNIKD Chaîne 21 UNIQ. Asc. bInterv Responsable Chaîne 10 Commentaire Commentaire Mémo texte DOCLEUNIKD DOCLEUNIKD Chaîne 21 UNIQ. Asc. A1.6 - DbDossier: table de réservoir de dossiers 3 0 Champ Libellé champ Type Taille Clé Clé Val. defaut Sens DOCLEUNIKD DOCLEUNIKD Chaîne 21 UNIQ. Asc. DECLEUNIKD DECLEUNIKD Chaîne 21 UNIQ. Asc. DossNom Nom Chaîne 150 DossCom Commentaire Mémo texte A1.7 -DbDemand: table de demandeurs Champ Libellé champ Type Taille Clé Clé VaL défaut Sens DECLEUNIKD DECLEUNIKD Chaîne 21 UNIQ. Asc. SoNom Société Chaîne 30 Multi Asc. SoActivite Activité Chaîne 100 Adresse Adresse Chaîne 100 CodePostal Code postal Chaîne 15 Ville Ville Chaîne 30 Pays Pays Chaîne 20 SoTel Téléphone Chaîne 20 SoFax Fax Chaîne 20 SoCommentaire Commentaire Chaîne 300 A1.8 DbPortelnf Champ Libellé champ Type Taille Clé Clé VaL défaut Sens IFCLEUNIKD IFCLEUNIKD Chaîne 21 UNIQ. Asc. POCLEUNIKD POCLEUNIKD Chaîne 21 UNIQ. Asc. DECLEUNIKD SOCLEUNIKD Chaîne 21 UNIQ. Asc. DateModif Modifié le Date (aaaammjj) 25 Multi Asc. Codeld Code identifica- Chaîne Concu tion Booléen 0 Concurrent ClesSecteur Secteur Chaîne 21 ModeReg Mode de Chaîne 5 commentaire règlement Mémo texte 21 ClesActivite Commentaire Chaîne Activité Annexe A2 - Liaisons entre tables et contraintes A2.1 - Contrainte DbPorteFiche DbPorteDoss: Dossier d'une fiche Source Relié Fichier DbPorteFiche DbPorteDoss Rubrique POCLEUNIKD POCLEUNIKD Cardinalités O,n 1,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2.2 - Contrainte DbPorteDoss DbDossAff: Affaires d'un dossier Source Relié Fichier DbPorteDoss DbDossAff Rubrique DFCLEUNIKD DFCLEUNIKD Cardinalités O,n 1,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2.3 - Contrainte DbDossAff DbInterven: Interventions d'une affaire Source Relié Fichier DbDossAff Dbinterven Rubrique DACLEUNIKD DACLEUNIKD Cardinalités O,n 1,1 3 0 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2.4 - Contrainte DbAffaire DbDossAff: Affaire prédéfinie Source Relié Fichier DbAffaire DbDossAff Rubrique AFCLEUNIKD AFCLEUNIKD Cardinalités O,n 0,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2.5 - Contrainte DbDossier DbPorteDoss: Dossier prédéfini (du demandeur) Source Relié Fichier DbDossier DbPorteDoss Rubrique DOCLEUNIKD DOCLEUNIKD Cardinalités O,n 1,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2.6 - Contrainte DbDossier DbAffaire: Affaire du réservoir de dossier Source Relié Fichier DbDossier DbAffaire Rubrique DOCLEUNIKD DOCLEUNIKD Cardinalités O,n 1,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2.7 - Contrainte_DbDemand_DbDossier: Dossier du tiers (demandeur) 20 Source Relié Fichier DbDemand DbDossier Rubrique DECLEUNIKD DECLEUNIKD Cardinalités O,n 1,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2. 8 - Contrainte DbPorteFiche DbPortelnf: Informations concernant la fiche Source Relié Fichier DbPorteFiche DbPortelnf Rubrique POCLEUNIKD POCLEUNIKD Cardinalités O,n 1,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié A2.9 - Contrainte DbDemand DbPortelnf: Informations concernant le demandeur Source Relié Fichier DbDemand DbPortelnf Rubrique DECLEUNIKD DECLEUNIKD Cardinalités O,n 1,1 Modification uniquement si pas d'enregistrement relié Suppression uniquement si pas d'enregistrement relié REVENDICATIONS 1. Dispositif de traitement de données (D), comprenant un système informatique (IU, MG) muni d'un code de programme capable i) de maintenir des tables de base (Ti) comportant des enregistrements, dont une première table (T 1) et une troisième table (T3), ainsi que d'établir des liens entre ces tables, et ii) de procurer une interface utilisateur (lU), permettant d'interagir avec lesdites tables de base (Ti) pour y créer ou modifier des enregistrements, afin d'assurer le suivi sélectif d'une pluralité d'activités, caractérisé en ce qu'il comprend une deuxième table (T2), dont chaque enregistrement comporte un premier champ, formant un pointeur vers un champ, formant clé, de ladite première table (T 1), et un deuxième champ, formant clé, en ce que ladite troisième table (T3) comprend, pour chaque enregistrement, un premier champ formant pointeur vers le deuxième champ, formant clé, de ladite deuxième table (T2), et en ce que ladite interface utilisateur (IU) est agencée pour imposer la création d'un enregistrement dans la deuxième table (T2) à chaque création d'un enregistrement dans la troisième table (T3), le lien entre un enregistrement de la troisième table (T3) et un enregistrement de la première table (Ti) se faisant par l'intermédiaire de la deuxième table (T2). 2. Dispositif selon la revendication 1, caractérisé en ce que le code de programme comprend un gestionnaire de tables en base de données (MG). 3. Dispositif selon la revendication 2, caractérisé en ce que le code de programme 2 5 comprend un logiciel d'application (LA) articulé sur ledit gestionnaire de tables en base de données (MG). 4. Dispositif selon l'une des revendications 1 et 3, caractérisé en ce que dans ladite troisième table (T3), chaque enregistrement comprend un deuxième champ, formant clé, et en ce qu'il comprend en outre, dans les tables de base, une quatrième table (T4) comprenant, pour chaque enregistrement, un premier champ formant pointeur vers le deuxième champ, formant clé, de ladite troisième table (T3). 5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que dans ladite troisième table (T3), chaque enregistrement comprend un troisième champ, formant clé, et en ce qu'il comprend en outre, dans les tables de base, une cinquième table (T5) dont chaque enregistrement comporte un deuxième champ formant clé primaire et vers lequel pointe ledit troisième champ de la troisième table (T3). 6. Dispositif selon l'une des revendications 1 à 5, caractérisé en ce que dans ladite deuxième table (T2), chaque enregistrement comprend un troisième champ, formant clé, et en ce qu'il comprend en outre, dans les tables de base, une sixième table (T6) dont chaque enregistrement comporte un deuxième champ formant clé primaire et vers lequel pointe ledit troisième champ de la deuxième table (T2). 7. Dispositif selon la combinaison des revendications 5 et 6, caractérisé en ce que dans ladite cinquième table (T5), chaque enregistrement comprend un premier champ, formant un pointeur vers ledit deuxième champ, formant clé primaire, de ladite sixième table (T6). 8. Dispositif selon l'une des revendications 1 à 7, caractérisé en ce qu'il comprend en outre, dans les tables de base, une septième table (T7) dont chaque enregistrement comporte un champ formant clé primaire, et en ce que l'une au moins desdites sixième table (T6), deuxième table (T2), cinquième table (T5) et troisième table (T3) comprend un champ, formant un pointeur vers ledit champ, formant clé primaire, de ladite septième table (T7). 9. Dispositif selon la combinaison des revendications 6 et 8, caractérisé en ce que ladite 2 0 sixième table (T6) comprend, pour chaque enregistrement, un premier champ formant ledit pointeur vers le champ, formant clé primaire, de ladite septième table (T7). 10. Dispositif selon l'une des revendication 1 à 9, caractérisé en ce qu'il comprend en 2 5 outre, dans les tables de base, une huitième table (T8) dont chaque enregistrement comporte un premier champ, formant un pointeur vers le champ, formant une clé, de ladite septième table (T7), et/ou un deuxième champ, formant un pointeur vers le champ, formant clé, de ladite première table (Tl).