Règles de recherche, d’exécution et de restitution¶

6.1 Définition de la veille¶

ID	Règle
RG-01	Une veille est définie en texte libre, utilisé directement pour orienter la recherche. L’interprétation par l’agent reste nécessaire, mais aucune reformulation distincte ni question de clarification n’est fournie dans le MVP. L’utilisateur peut modifier ses paramètres dans l’interface.
RG-02	Les modifications ne suppriment pas les résultats conservés. Une exécution utilise les paramètres lus à son démarrage effectif ; une recherche en attente utilise donc les derniers paramètres disponibles à ce moment.

6.2 Sources et collecte¶

ID	Règle
RG-03	Chaque veille possède sa liste de sites et peut sélectionner plusieurs boîtes mail. Elle peut utiliser les sites, les messages, la recherche Internet ou une combinaison.
RG-04	La recherche Internet est sélectionnable par veille et activée par défaut. L’agent peut utiliser des API de recherche. Les sites découverts servent uniquement à l’exécution en cours ; leurs références sont conservées avec les résultats, sans ajout automatique à la configuration.
RG-05	Seuls les sites publics sont pris en charge. Le contenu complet est recherché. Un navigateur automatisé permet d’accéder aux pages nécessitant JavaScript.
RG-06	L’exploration respecte une profondeur maximale commune à l’installation. Pour une source configurée, elle part de l’adresse configurée ; pour un résultat de recherche Internet, de la page trouvée, sans retour obligatoire à l’accueil.
RG-07	L’exploration reste sur le site et ses sous-domaines. Elle ne suit pas les liens vers d’autres sites. La définition technique précise du périmètre de domaine et le traitement des redirections restent à concevoir.
RG-08	La profondeur limite les liens suivis successivement ; sa convention de comptage et sa valeur par défaut restent à définir. Aucun nombre maximal de pages n’est fixé : la profondeur ne constitue pas une limite de largeur d’exploration. La durée maximale borne la collecte.
RG-09	Le MVP utilise un seul mode de connexion aux messageries, encore indéterminé. Les connexions et identifiants sont persistés dans le fichier de configuration ; les boîtes sont sélectionnées par veille dans l’interface. Dossiers et filtres restent à définir.
RG-10	La messagerie est strictement en lecture seule : ne pas marquer comme lu, déplacer ou supprimer un message. Plusieurs veilles peuvent traiter le même message indépendamment.
RG-11	Seul le corps du message est analysé. Les pièces jointes et les PDF sont hors MVP. Un lien vers un article public peut être ouvert même si son site n’est pas configuré ; seul l’article ciblé est lu, sans exploration de ses autres pages.
RG-12	Les e-mails sont sélectionnés selon leur date de réception. Pour les pages web, la publication ou une mise à jour apportant de nouvelles informations pendant la période peut rendre le contenu pertinent.
RG-13	Un article pertinent encore inconnu peut être intégré sans date de publication, avec la mention « date inconnue ». Un article déjà connu à la même URL peut être réanalysé si son contenu apporte des nouveautés.
RG-14	Utiliser le contenu extractible et signaler toute extraction partielle. Une consultation aboutie sans élément disponible sur la période est un succès de consultation : boîte sans message ou API de recherche retournant zéro résultat. Si des contenus sont trouvés mais qu’aucun ne peut être lu, cette collecte n’est pas réussie. Le simple chargement d’une page ou d’une liste de résultats ne vaut pas lecture d’un article. L’issue globale suit la priorité définie en 6.8.

6.3 Admission, programmation et file d’attente¶

ID	Règle
RG-15	La création demande immédiatement une première recherche. Contrôler les sources actives à l’admission puis au démarrage effectif. Sans source active, ignorer la demande ou la retirer de la file sans créer d’exécution, d’erreur ni de trace d’exécution. Une source activée dont la configuration obligatoire est absente ou invalide constitue un problème de configuration, pas une absence de source : signaler le problème dans l’interface et ne pas admettre la demande, ou la retirer de la file si elle y est déjà. Les incidents d’accès effectifs suivent les règles de résultat partiel ou d’échec.
RG-16	Chaque veille a sa programmation quotidienne, hebdomadaire ou mensuelle avec heure et jour appropriés. Le fuseau est celui de l’installation. Si le jour mensuel n’existe pas, exécuter le dernier jour du mois.
RG-17	La suspension désactive la programmation. La réactivation demande immédiatement une recherche de rattrapage, puis reprend la programmation. Une veille suspendue peut être lancée manuellement.
RG-18	Une seule recherche s’exécute à la fois pour toute l’installation. Les autres attendent dans une file selon l’ordre d’arrivée, sans priorité pour les demandes manuelles. Les demandes « immédiates » ne contournent pas cette file.
RG-19	Si une veille a déjà une recherche en attente ou en cours, tout nouveau lancement de cette même veille est ignoré.
RG-20	Au redémarrage, créer au plus un rattrapage des échéances manquées par veille dont la programmation est active, sans doublon avec une demande persistée. Ne créer aucun rattrapage automatique pour une programmation suspendue. Les demandes manuelles déjà en attente restent valides, même si la programmation est suspendue. Les demandes persistées gardent leur priorité ; les nouveaux rattrapages sont ajoutés à la suite.
RG-21	La file persiste après arrêt. Une exécution interrompue avant validation de sa publication est relancée en tête depuis le dernier curseur enregistré, même si sa programmation a été suspendue après son démarrage. Les autres demandes gardent leur ordre. Une recherche dont la publication a été validée n’est pas relancée au seul motif que l’envoi e-mail a été interrompu.

6.4 Fenêtre temporelle et curseur¶

ID	Règle
RG-22	La première recherche couvre une période configurable, de 7 jours par défaut. Si elle échoue complètement, conserver sa période initiale à rattraper pour les prochains lancements ; ne pas déplacer sa borne de début de manière glissante.
RG-23	Après finalisation réussie, valider ensemble les résultats de l’exécution et son curseur, fixé à l’heure de validation de publication, avant l’envoi e-mail. Cette règle s’applique au succès, au résultat partiel et à la recherche écourtée finalisable. Sans nouveauté, valider l’issue et le curseur de la même manière. Un échec complet ou une demande retirée avant démarrage ne modifie pas le curseur. Une suspension laisse l’exécution en cours appliquer ces règles normales.
RG-24	Il n’existe pas de curseur distinct par source. Une réussite partielle fait avancer le curseur global : les périodes manquées par les sources indisponibles ne font pas l’objet d’un rattrapage spécifique.

La fin de recherche correspond à la validation de sa publication, avant la diffusion. Les deux étapes ont des issues distinctes. La recherche suivante peut commencer une fois cette publication validée ; la diffusion n’étend pas la période de recherche et ne doit pas bloquer indéfiniment la file.

La borne de fin et l’absence de rattrapage par source rendent la couverture non exhaustive : une information arrivée après la consultation d’une source mais avant la fin de recherche, ou sur une source indisponible, peut être manquée. Le MVP expose les limites observées sans promettre une collecte exhaustive. Les conventions d’inclusion des bornes et de normalisation des dates restent techniques.

6.5 Sujets, nouveautés et provenance¶

ID	Règle
RG-25	Le regroupement et le dédoublonnage sont limités à une veille. Ils portent sur les sources web et mail ensemble, et sur les recherches antérieures de cette veille.
RG-26	Regrouper les apports sur un même fait, événement ou évolution identifiable. Ne pas fusionner uniquement parce que deux informations concernent la même entreprise ou un thème commun. Une nouvelle source répétant un fait connu enrichit sa provenance sans générer de nouveauté dans la synthèse ou l’e-mail. Un fait complémentaire ou une évolution datée enrichit le sujet et entre dans les nouveautés.
RG-27	Conserver les informations précédentes et identifier les nouveaux apports par leur date et leurs sources. Une fiche sujet expose l’ensemble cumulé.
RG-28	Signaler les affirmations incompatibles portant sur le même fait dans le même contexte, avec leurs sources, sans trancher. Une évolution chronologique ou une correction explicitement présentée comme telle par la source est un nouvel apport daté ; ne pas la qualifier automatiquement de contradiction. Les méthodes de détection restent à concevoir.
RG-29	La synthèse et l’e-mail d’une recherche présentent uniquement les nouveautés. La consultation par veille donne accès à l’ensemble conservé, y compris les résultats précédents, sans recherche par mots-clés dans le MVP.

6.6 Limites, finalisation, échecs et annulation¶

ID	Règle
RG-30	La durée maximale commune borne la collecte. À son terme, arrêter la collecte et signaler qu’elle a été écourtée. Si au moins une consultation a abouti, y compris avec zéro résultat, finaliser ce qui est disponible. Si aucune consultation n’a abouti, déclarer un échec complet : le caractère écourté ne transforme pas une absence totale de consultation réussie en succès.
RG-31	La finalisation dispose d’un délai de sécurité distinct, commun à l’installation. Elle comprend la consolidation, la synthèse et les éventuelles vérifications internes. Le dépassement de ce délai entraîne un échec complet.
RG-32	Publier seulement après finalisation réussie, en cohérence avec le curseur. Un échec de synthèse ou de finalisation ne publie aucun résultat de cette exécution et laisse le curseur inchangé ; l’historique publié reste conservé. En l’absence de nouveauté, un bilan déterministe suffit : aucun appel de génération de synthèse vide n’est requis. Des références supplémentaires à des faits connus peuvent être conservées sans déclencher de notification.
RG-33	Une consultation aboutie sans contenu sur la période, ou un contenu lisible sans information pertinente, compte comme consultation réussie. Avec au moins une consultation réussie, poursuivre jusqu’à finalisation : succès si aucune limite n’est rencontrée, résultat partiel si des accès échouent ou des extractions sont incomplètes, recherche écourtée si la durée de collecte est atteinte. Sans aucune consultation réussie, l’issue est un échec complet. Les limites observées restent visibles, y compris en cas de zéro nouveauté.
RG-34	La suspension annule la recherche de la veille en attente, sans effet sur les résultats antérieurs ni le curseur. Une recherche déjà en cours se termine normalement : collecte, finalisation, publication, avancement du curseur selon son issue et envoi éventuel. L’interface indique que cette recherche se termine tandis que les prochaines échéances sont suspendues.
RG-35	Un échec complet est tracé et déclenche une alerte e-mail. Il n’entraîne pas de nouvelle tentative automatique de recherche : attendre le prochain lancement manuel ou programmé. La relance au redémarrage après interruption relève de RG-21, non d’une tentative après échec complet.

6.7 Restitution et envoi¶

ID	Règle
RG-36	Résumés, synthèses et e-mails sont en français. Le format commun comprend une courte synthèse générale, puis pour chaque sujet nouveau ou enrichi : titre, résumé des nouveautés et références. Chaque affirmation factuelle restituée doit être étayée par les contenus collectés ; ne pas ajouter de fait issu uniquement des connaissances du modèle. Les templates sont différés.
RG-37	Les résultats restent consultables sur le web. Le réglage par veille est intitulé « Envoyer les nouveautés par e-mail ». S’il est activé et des nouveautés existent, envoyer après publication à l’adresse unique de l’installation. Le désactiver ne désactive pas les alertes techniques d’échec prévues par RG-35.
RG-38	Sans nouveauté, ne pas envoyer d’e-mail de résultats ; tracer l’exécution. Cela vaut aussi pour une recherche écourtée sans nouveauté. Avec des nouveautés malgré une collecte partielle ou écourtée, envoyer et préciser les limites, dont les sources non consultées.
RG-39	L’envoi possède un état distinct de la recherche. Son échec conserve résultats et curseur, ne relance pas la recherche et est tracé ; aucun renvoi manuel dans le MVP. Si une interruption laisse incertaine la remise d’un e-mail, tracer un envoi non confirmé et ne pas le renvoyer automatiquement. Un échec d’envoi d’alerte est également tracé. La stratégie technique doit éviter de publier deux fois les mêmes apports lors d’une reprise.
RG-40	Les résultats et synthèses restent conservés sans limite de durée dans le MVP. Aucun archivage, suppression, reclassement automatique ou nettoyage des informations n’est fourni dans cette version.

6.8 Matrice des issues¶

Les e-mails de nouveautés supposent le mode e-mail activé pour la veille. Les alertes d’échec sont des notifications techniques distinctes.

Situation	Résultats de l’exécution	Curseur	E-mail	Trace
Aucune source active, y compris au démarrage différé	Aucune exécution ; demande retirée si nécessaire	Inchangé	Aucun	Aucune trace d’exécution
Succès avec nouveautés	Publication après finalisation	Heure de publication	Nouveautés si activé	Succès
Succès sans nouveauté, dont consultation vide	Bilan et éventuelles références supplémentaires ; historique préservé	Heure de publication	Aucun	« Aucune nouveauté »
Réussite partielle avec nouveautés	Publication et mention des limites	Heure de publication	Nouveautés et sources non consultées si activé	Partielle et incidents
Réussite partielle sans nouveauté	Bilan, limites et éventuelles références supplémentaires	Heure de publication	Aucun e-mail de résultats	Partielle, sans nouveauté
Collecte écourtée avec consultation aboutie et finalisation réussie	Publication des éventuelles nouveautés et références supplémentaires	Heure de publication	Nouveautés et mention « écourtée » si activé ; sinon aucun	Recherche écourtée et limites
Aucune consultation aboutie, y compris après durée maximale	Aucun résultat publié	Inchangé	Alerte d’échec	Échec et cause de l’arrêt
Synthèse en échec ou délai de finalisation dépassé	Aucun résultat publié	Inchangé	Alerte d’échec	Échec
Suspension avec recherche en attente	Demande en attente annulée ; historique préservé	Inchangé	Aucun pour la demande annulée	Annulation de l’attente
Suspension avec recherche en cours	Traitement poursuivi et publication selon son issue normale	Selon l’issue normale	Selon l’issue normale et l’option d’envoi	Programmation suspendue ; recherche poursuivie
Arrêt avant publication validée	Relance en tête au redémarrage	Dernier curseur conservé	Selon l’issue du traitement relancé	Reprise à suivre
Arrêt après publication validée	Résultats conservés, aucune nouvelle collecte pour cette exécution	Avancement conservé	État d’envoi conservé ; pas de renvoi automatique si remise incertaine	Envoi non confirmé si nécessaire
Échec d’envoi après recherche réussie	Résultats conservés	Avancement conservé	Envoi échoué ; pas de renvoi manuel	Échec d’envoi
Échec d’envoi de l’alerte	Aucun changement de l’issue de recherche	Inchangé	Alerte non délivrée	Échec d’envoi de l’alerte

L’issue suit cet ordre : absence totale de consultation réussie → échec ; sinon finalisation en échec → échec ; sinon durée de collecte atteinte → écourtée ; sinon incidents de consultation ou d’extraction → partielle ; sinon succès. Le nombre de nouveautés détermine l’e-mail de résultats, pas la réussite de la consultation. Une recherche écourtée conserve aussi les détails des incidents rencontrés.

6.9 Interprétation simple des nouveautés¶

Situation	Traitement du MVP
Copie ou reformulation d’un fait connu	Pas de nouveauté ; éviter le doublon.
Nouvelle source confirmant le même fait	Ajouter la provenance après finalisation, sans notifier ce seul ajout.
Nouveau fait complémentaire sur le même événement	Enrichir le sujet, dater et sourcer l’apport ; le restituer comme nouveauté.
Événement distinct concernant la même organisation	Conserver un sujet distinct.
Évolution datée ou correction explicitement annoncée	Conserver les éléments précédents et ajouter l’évolution datée ; ne pas conclure automatiquement à une contradiction.
Affirmations incompatibles dans le même contexte	Présenter les versions et leurs sources, sans choisir une vérité automatiquement.
Contenu sans rapport identifiable avec la demande	Ne pas le retenir dans les sujets ni la synthèse.

Ces règles ne requièrent ni validation humaine supplémentaire ni score configurable. Les méthodes de rapprochement restent à choisir en conception et à évaluer sur des exemples génériques.