Chrono

1. Fiabilisation du socle Azure et du déploiement

Diagnostic et correction de la chaîne de déploiement Azure App Service : vérification Nginx, nettoyage des caches Laravel, redémarrage des workers, sécurisation du packaging et préparation d’un scheduler applicatif dédié.

Impact : réduction des risques de code obsolète, routes en cache et comportements divergents entre local et production.

2. Industrialisation des synchronisations automatiques

Mise en place d’une synchronisation automatique paramétrable par folder, planifiée toutes les 15 minutes, avec enchaînement contrôlé SharePoint puis OpenWebUI. Ajout de garde-fous contre les runs concurrents et conservation du comportement manuel existant.

Impact : automatisation fiable du cycle d’ingestion sans refonte profonde.

3. Amélioration du suivi métier des traitements

Structuration des statuts, compteurs et affichages autour des runs SharePoint et OpenWebUI : distinction entre succès, erreurs, warnings et fichiers filtrés, ajout de libellés fonctionnels lisibles, suivi des ajouts/modifications/suppressions.

Impact : meilleure lisibilité opérationnelle et diagnostic plus rapide des traitements.

4. Optimisation et sécurisation de l’indexation OpenWebUI

Correction d’un problème mémoire en production lors de l’indexation, adaptation du traitement des fichiers volumineux, ajout des métadonnées source SharePoint et création d’un rattrapage sans réindexation.

Impact : indexation plus robuste, traçabilité renforcée et limitation des opérations coûteuses.

5. Mise en place des alertes d’exploitation

Développement d’un mécanisme d’alertes email pour les erreurs, warnings et changements significatifs côté SharePoint/OpenWebUI, avec configuration Mailgun et diagnostic SMTP en production.

Impact : meilleure supervision des synchronisations et réduction du temps de détection des incidents.

GentleShare : Plateforme de synchronisation SharePoint → OpenWebUI

Développement de GentleShare, une application d’administration destinée à synchroniser des contenus SharePoint avec OpenWebUI, dans une logique d’assistant IA d’entreprise alimenté par les documents internes.

Sur la période du 23 au 28 avril 2026, le projet est passé d’un socle Laravel initial à une application structurée autour de Laravel, Filament, MySQL, Microsoft Graph et OpenWebUI. L’objectif n’était plus seulement de déclencher une synchronisation, mais de construire une plateforme exploitable : suivi des dossiers, gestion des fichiers, synchronisations asynchrones, historique des traitements, statuts visibles dans l’interface et meilleure observabilité des erreurs.

Un travail important a porté sur la fiabilisation des synchronisations longues. La synchronisation SharePoint a été sortie du cycle HTTP classique pour être confiée à des jobs Laravel, avec des runs persistés, un état de progression et une interface capable d’indiquer clairement le dernier traitement exécuté. Cette évolution prépare l’application à des volumes réels, en évitant les blocages liés aux timeouts des requêtes web.

Côté OpenWebUI, l’intégration a été renforcée avec une meilleure gestion des temps de traitement, des warnings fonctionnels et des cas particuliers comme les fichiers sans contenu exploitable, les extensions exclues, les fichiers déjà présents ou les fichiers SharePoint de taille nulle. L’application donne désormais une lecture plus claire de ce qui a été traité, ignoré ou rejeté, fichier par fichier.

Le projet a également été réaligné pour un déploiement Azure plus propre : workflow GitHub Actions corrigé, packaging applicatif clarifié, configuration nginx/startup revue, variables d’environnement identifiées, et documentation technique remise à plat. Les fichiers README, architecture, développement, produit et roadmap ont été recréés pour refléter l’état réel du projet.

Bilan : GentleStacks dispose désormais d’une base applicative cohérente pour piloter la synchronisation SharePoint–OpenWebUI, avec une architecture plus robuste, une meilleure traçabilité des traitements et une documentation alignée avec l’usage réel du produit.

Fiabilisation du socle avant intervention

La journée a surtout porté sur deux mises à niveau sensibles en environnement de production : OpenWebUI et n8n, hébergés sur VM Azure. Le point clé n’a pas été l’exécution de l’upgrade en elle-même, mais la remise à plat de l’environnement réel avant intervention.

Côté OpenWebUI, le travail a commencé par un diagnostic de l’architecture effectivement en service. Cela a permis de corriger une hypothèse initiale sur l’usage d’une base locale et de confirmer une configuration plus structurée, appuyée sur Azure Database for PostgreSQL avec séparation entre base applicative et base vectorielle, pilotée via systemd. Cette lecture juste du socle a ensuite guidé la préparation de migration, notamment sur les prérequis Python, le mode d’exécution et la stratégie de sauvegarde.

Dans le même esprit, la montée de version de n8n a nécessité un arbitrage préalable sur la chaîne technique. L’échec initial ne venait pas de l’application elle-même, mais d’une incompatibilité entre la version visée et le runtime Node.js présent sur la VM. La séquence a donc été reprise proprement : sécurisation d’un retour arrière, remise en état du service, puis upgrade du runtime avant celui de l’application.

Sauvegardes exploitables et corrections de socle

Les deux interventions ont été menées avec un souci explicite de réversibilité. Pour OpenWebUI, des dumps PostgreSQL vérifiés ont été produits sur les deux bases. Un point bloquant d’outillage est apparu au passage : le client PostgreSQL installé sur la VM n’était pas adapté à la version du serveur Azure. Le contournement a consisté à installer un client PostgreSQL 18 afin d’obtenir des sauvegardes réellement fiables avant toute modification.

Sur n8n, la sécurisation a porté sur les éléments critiques d’exploitation : unité systemd, override, état de l’installation globale npm et archive du répertoire applicatif. Ce cadre a permis de traiter sans précipitation une corruption partielle de l’installation globale npm, avec retour temporaire vers une version stable pour restaurer rapidement le service, puis reprise propre de l’upgrade après correction d’un problème de répertoire global (ENOTEMPTY).

Upgrade contrôlé et validation opérationnelle

La mise à jour d’OpenWebUI de 0.8.12 vers 0.9.1 a ensuite été réalisée dans le virtualenv de production, avec correction d’un premier échec lié aux droits d’écriture sur l’environnement Python. Après redémarrage, les contrôles ont confirmé un retour nominal du service : écoute applicative, endpoints de santé disponibles et version attendue bien déployée.

Pour n8n, la trajectoire retenue a conduit à une bascule du runtime système de Node 20 vers Node 22, puis à la mise à niveau de l’application vers n8n 2.18.0. La validation finale a porté à la fois sur la cohérence binaire/package/service et sur la continuité de service de l’ensemble de la VM, y compris OpenWebUI et Caddy.

Au-delà des versions installées, la journée a surtout consolidé l’exploitabilité de la plateforme : sauvegardes vérifiées, environnement nettoyé, documentation d’architecture mise à jour et trajectoire de retour arrière clarifiée pour les prochaines interventions.

Pilotage marketing : métrique simplifiée et alignée sur l’existant

La journée a surtout porté sur la fiabilisation de la lecture marketing dans Nova, avec un double objectif : mieux suivre la délivrabilité des notifications et corriger une incohérence métier sur l’analyse des campagnes coupons. Un nouveau KPI a été introduit sur la dashboard Marketing pour suivre, au fil des jours, le ratio entre notifications émises et notifications effectivement reçues à partir des enregistrements de individual_notifications.

L’arbitrage a été volontairement sobre : la métrique a été implémentée sous forme de Trend native Nova plutôt que via une card front sur mesure. Ce choix permet de garder une instrumentation homogène avec le reste du back-office, de limiter la complexité technique et d’éviter d’ajouter une dépendance JavaScript peu justifiée au regard du besoin.

Relecture métier de l’analyse des campagnes coupons

Le point le plus structurant a concerné la card d’analyse des bons par campagne. L’investigation a mis en évidence un écart entre la logique de calcul historique et le fonctionnement réel des campagnes ExpirationReminder. Jusqu’ici, l’écran s’appuyait sur les coupons créés par la campagne ; or, dans ce cas précis, la campagne ne génère pas de nouveaux bons, elle relance des clients à propos de coupons déjà existants. Les valeurs nulles observées n’étaient donc pas un simple défaut de données, mais la conséquence directe d’une hypothèse fonctionnelle inadaptée.

La correction a consisté à introduire un traitement ciblé dans la route API concernée : filtrer les notifications réellement envoyées sur la période, récupérer les coupon_id référencés, puis recalculer les indicateurs métier sur les coupons effectivement touchés par la campagne. La logique historique a été conservée pour les autres types de campagnes, ce qui cadre le correctif et réduit le risque de régression.

Validation sur données réelles et sécurisation de l’intégration

La mise au point a été vérifiée de bout en bout après import local de la base de production, notamment sur la campagne de rappel d’expiration à 5 jours. Ce contrôle a permis de confirmer la cohérence des volumes renvoyés par le backend — notifications envoyées, coupons concernés, ouverts, expirés et utilisés — et d’écarter l’hypothèse d’un problème de calcul résiduel côté API.

Le dernier point a porté sur l’environnement cible, avec la correction d’une erreur de namespace sur la nouvelle métrique Nova. Le chargement de la dashboard en production est désormais sécurisé, ce qui clôt une séquence utile de clarification métier, d’ajustement backend et de stabilisation de l’instrumentation marketing.

Structuration du cas d’usage Vous nous manquez

La journée a surtout porté sur la mise au propre du pilotage des notifications mobiles dans Nova. L’enjeu n’était pas d’ajouter un type de campagne de plus, mais de le cadrer correctement : formulaire réduit aux seuls champs réellement utiles à la notification mobile, dates masquées côté interface et sécurisées par défaut dans le modèle avec une plage permanente. Ce choix simplifie l’administration sans laisser de zone grise sur le comportement réel de la campagne.

Dans le même mouvement, une règle métier a été ajoutée pour empêcher la coexistence de plusieurs campagnes. Le point important est que ce contrôle a été porté au niveau de la validation applicative, et non laissé à la seule interface Nova. Cela garantit un fonctionnement cohérent même si la création passe un jour par un autre point d’entrée.

Rattachement explicite des notifications aux campagnes

L’arbitrage principal de la journée a concerné le modèle de données. Le rattachement d’une notification à sa campagne repose désormais sur une vraie colonne campaign_id dans individual_notifications, plutôt que sur une simple information embarquée dans le payload. La migration a été créée et appliquée, puis le lien a été intégré dans les principaux flux de génération.

Ce choix rend les relations Eloquent plus fiables, facilite les filtres Nova et prépare un suivi plus propre des notifications par campagne réelle. Il permet aussi de sortir progressivement d’une logique de codes techniques utile historiquement, mais moins robuste dès qu’il faut analyser ou faire évoluer le dispositif.

Remise à niveau du reporting

Enfin, la carte de statistiques Nova a été reprise de manière ciblée : correction de l’initialisation des filtres de dates, ajustements d’ergonomie, harmonisation des libellés et adaptation du calcul backend pour regrouper d’abord par campaign_id quand il est présent, avec repli sur campaign_code pour l’historique. Le filtre Nova des notifications a été aligné sur cette même logique, avec affichage des noms de campagnes plutôt que des codes. L’ensemble améliore à la fois la lisibilité côté métier et la fiabilité du suivi.

Reprise des points de rupture sur les campagnes fidélité

La journée a surtout porté sur la remise à plat de plusieurs flux sensibles autour des campagnes marketing et des bons fidélité. Le travail a commencé par une reconstitution complète du parcours de la campagne « Vous nous manquez », depuis Nova jusqu’à la génération des coupons, leur export puis leur usage en caisse. Cette reprise a permis d’isoler un écart structurel entre le flux historique et l’implémentation actuelle : la génération batch contournait les événements Eloquent, ce qui cassait implicitement le déclenchement des notifications associées.

Le correctif a été appliqué au plus près du point de rupture, dans le service de génération, avec création explicite des notifications individuelles pour les coupons produits en batch. L’intérêt de cette approche est de rétablir un comportement cohérent sans remettre en cause la file d’attente existante ni la chaîne d’envoi OneSignal.

Dans le même mouvement, une dérive sur le format des couponnumber a été corrigée : des UUID remplaçaient le format métier attendu. Le service a été réaligné sur la logique standard de numérotation, avec ajout d’une protection contre les doublons dans les traitements batch. Un outillage de rattrapage a aussi été préparé pour la production via une commande Artisan dédiée, filtrable par date et sécurisée par un mode dry-run, afin de corriger les coupons déjà émis sans prise de risque inutile.

Lecture plus fiable des notifications marketing

Un second axe a consisté à rendre le pilotage des notifications plus lisible côté back-office. Les métriques Nova natives ne couvraient pas correctement le besoin de lecture consolidée par période ; le choix a donc été fait de développer une card Nova custom dédiée aux notifications individuelles. L’interface a été recentrée sur un tableau synthétique unique, avec campagnes en lignes et statuts en colonnes, pour privilégier une lecture métier directe plutôt qu’une juxtaposition de widgets. L’ensemble a été intégré comme package local, aligné visuellement sur les composants déjà en place et validé jusqu’à la compilation front.

Repositionnement d’un déclenchement métier

Enfin, le déclenchement du bon de bienvenue a été déplacé dans le parcours d’inscription. Le bon n’est plus créé à l’enregistrement initial, mais après validation effective de l’adresse e-mail, lors de la première vérification réussie. Ce repositionnement aligne mieux le déclenchement métier sur un acte utilisateur réellement abouti et clarifie la séparation entre création du bon et envoi du message de bienvenue. La couverture de test a été ajustée en conséquence pour sécuriser ce changement.

En parallèle, l’analyse des relances avant expiration a permis d’isoler une cause probable sur les notifications envoyées alors qu’une campagne semblait inactive : l’état actif est bien contrôlé à la mise en file, mais pas revalidé au moment de l’envoi. Le point est désormais cadré pour un correctif ciblé.

Exécution planifiée Azure : correction et clarification

La journée a porté sur un sujet de fiabilité opérationnelle concret : le non-déclenchement d’une campagne de relance en production. L’analyse a permis de reconstituer précisément la chaîne d’exécution des campagnes planifiées, de valider les horaires attendus et d’isoler un défaut de configuration dans l’usage du scheduler Laravel au sein d’Azure WebJobs.

Le dispositif a ensuite été remis en cohérence avec le modèle d’exécution Azure :

• correction du script scheduler pour un fonctionnement conforme au mode Triggered / Scheduled ;
• ajout d’un settings.job pour expliciter la planification ;
• préparation d’un package de déploiement schedulerjob.zip propre pour publication sur Azure App Service ;
• durcissement des scripts d’exploitation.

Au-delà du correctif, un arbitrage d’architecture a été validé entre :

• un WebJob planifié dédié au scheduler Laravel ;
• un WebJob continu distinct pour le traitement de la queue.

Cette séparation renforce la lisibilité d’exploitation et réduit l’ambiguïté entre orchestration temporelle et exécution continue des traitements.

Levée d’ambiguïté sur la planification Azure

Un travail de vérification croisée a été mené entre la documentation Microsoft et le comportement réel du portail Azure afin de sécuriser le format d’expression CRON effectivement accepté par l’interface WebJobs. La configuration retenue repose donc sur le comportement réellement validé par la plateforme, et non sur une lecture théorique de la documentation uniquement.

Notifications OneSignal : contrôle applicatif réaligné sur le réel

En parallèle, le flux d’envoi push a été repris pour traiter un point souvent masqué par les APIs de notification : un utilisateur peut exister côté OneSignal via son External ID sans disposer d’une souscription push active.

Le traitement a été complété par une pré-vérification explicite avant envoi réel, permettant de distinguer les cas :

• utilisateur introuvable ;
• aucune souscription push associée ;
• push désactivé.

Ce correctif remplace un message générique peu exploitable et aligne le comportement applicatif sur le modèle réel observé côté mobile et côté OneSignal. Dans la continuité des travaux mensuels de maintenance et d’évolution d’applications Laravel sur mesure, cette journée consolide surtout la prévisibilité d’exploitation : mieux déclencher, mieux séparer les responsabilités, et mieux qualifier les erreurs avant qu’elles ne deviennent des incidents fonctionnels.

Stabilisation du back-office Nova

La journée a porté sur un objectif clair : améliorer l’exploitabilité métier du back-office tout en traitant une fragilité réelle observée en production sur Nova. Dans la continuité des évolutions menées ce mois sur l’application de fidélité web/mobile sous Laravel et Nova, le travail a combiné enrichissement fonctionnel, diagnostic d’incident et remise à plat d’un point d’architecture sensible.

Filtres métier directement exploitables

Sur la ressource de notifications individuelles, mise en place de filtres immédiatement utiles en exploitation :

• filtre de statut centré sur les états opérationnels Envoyée / Échec ;
• filtrage par période sur le champ Envoyé le, structuré autour de deux bornes date distinctes.

L’implémentation a volontairement retenu les filtres date natifs de Nova plutôt qu’un composant sur mesure, avec un arbitrage en faveur de la maintenabilité, de la compatibilité et d’un comportement plus prévisible dans l’interface d’administration.

Diagnostic de la cause racine en production

L’analyse de l’incident a permis d’écarter rapidement la piste de la ressource notifications pour isoler la vraie source du plantage : un endpoint de dashboard Analytics appelé avec le paramètre 3. La cause bloquante provenait d’une fonction globale non résolue (getZoneBillingStats) utilisée dans un contexte de closure sérialisée, avec en complément un point de vigilance sur les signatures de filtres attendues par Nova v5.

Ce travail a permis de clarifier le périmètre exact de l’incident et d’éviter une correction superficielle sur le mauvais composant.

Correction structurelle plutôt que contournement

Le correctif a consisté à sortir la logique métier des routes Analytics pour la recentrer dans un service applicatif dédié : ZoneBillingService. Les routes Nova appellent désormais explicitement le service via le container Laravel, ce qui réduit la dépendance au chargement des routes et sécurise davantage le comportement en environnement caché / sérialisé.

La requête SQL a également été durcie par qualification explicite des colonnes afin de prévenir les ambiguïtés et erreurs de sélection.

Validation et préparation d’exploitation

Les fichiers modifiés ont été contrôlés syntaxiquement (php -l) et la séquence de remise en production a été préparée de façon explicite : purge des caches applicatifs, régénération éventuelle du cache de routes, puis retest ciblé de l’endpoint Analytics.

Au-delà du correctif du jour, cette intervention renforce une dynamique annuelle de maintenance et d’évolution d’applications métiers avec un même fil directeur : rendre les composants Laravel/Nova plus lisibles, plus robustes et plus sûrs en exploitation.

Sécurisation du parcours d’authentification

La journée a été consacrée à un durcissement ciblé d’une application de fidélité Laravel / Nova, avec un objectif clair : fermer l’accès fonctionnel tant que l’identité email n’est pas confirmée, sans dégrader la continuité du parcours utilisateur.

Les évolutions portent à la fois sur le modèle utilisateur, les contrôleurs d’inscription et de vérification, ainsi que sur la protection des routes sensibles par auth + verified. Ce travail ne relève pas d’un simple ajustement d’interface : il remet en cohérence l’enchaînement inscription → vérification → accès applicatif, en supprimant les contournements implicites et les redirections hétérogènes.

La vue de vérification a également été reprise en français, intégrée au layout principal et rendue plus explicite sur les actions possibles, notamment le renvoi du message. Le courriel de vérification a, lui aussi, été personnalisé via un template dédié afin d’aligner le fond et la forme du dispositif.

Notifications coupon : logique métier clarifiée

Un second axe a consisté à affiner la logique de sélection des templates de notification pour les coupons. Les coupons rattachés à une facture — ou relevant des types Classic / Threshold — basculent désormais explicitement sur la campagne NewCouponNotification, tandis que les autres cas peuvent continuer à exploiter la campagne source du coupon.

Ce réglage améliore la lisibilité de la règle métier et réduit les ambiguïtés dans l’émission des notifications. En parallèle, l’injection du prénom a été normalisée en Title Case avec repli sur Client, afin de fiabiliser le rendu des placeholders dans les messages réellement envoyés.

Mise sous contrôle back-office et interopérabilité API

Côté Nova, les champs de titre, contenu et lien de notification ont été rendus configurables pour NewCouponNotification, avec rappel des placeholders disponibles ({{prenom}}, {{nom}}, {{montant_bon}}, {{date_expiration}}). L’enjeu est moins d’ajouter des champs que de redonner une maîtrise éditoriale propre au back-office sur un scénario désormais central.

Enfin, les endpoints renvoient maintenant explicitement text/plain; charset=ISO-8859-1. Ce point, discret mais important, sécurise l’interopérabilité avec les systèmes consommateurs et évite des écarts d’affichage ou d’interprétation côté intégration.

Dans la continuité du mois, cette intervention prolonge un travail de maintenance évolutive orienté robustesse applicative, cohérence fonctionnelle et qualité d’intégration sur un socle métier sur mesure.

Campagnes Nova : structuration utile, pas seulement cosmétique

La journée a porté sur la fiabilisation du paramétrage des campagnes de notifications dans l’application de fidélité sous Laravel / Nova, avec un travail centré sur l’usage réel côté back-office. L’interface a été restructurée pour afficher les champs métier de façon conditionnelle selon le type de campagne — bienvenue, rappel d’expiration, anniversaire fidélité — afin de limiter les ambiguïtés de saisie et de rendre chaque configuration plus cohérente avec son intention opérationnelle.

Dans la même logique, les libellés ont été harmonisés et les champs liés à la notification ont été repositionnés avant les dates, ce qui améliore la lisibilité du formulaire et réduit les risques de paramétrage incohérent.

Données de notification rendues pilotables

Le modèle campaigns a été étendu avec notification_title, notification_content et notification_link, via migration exécutée et validée en environnement applicatif. Ces attributs sont désormais exposés dans Nova uniquement pour les campagnes concernées.

Ce point est significatif : le contenu de notification n’est plus traité comme une logique périphérique ou implicite, mais comme une donnée métier gouvernée au niveau de chaque campagne. Cela renforce la maintenabilité de l’application et prépare des évolutions fonctionnelles plus propres sur le périmètre fidélité / CRM, dans la continuité des travaux mensuels d’évolution d’applications métiers sur mesure.

Encadrement des contraintes OneSignal et correction XLProg

Un travail de diagnostic a également été mené sur les contraintes documentaires OneSignal afin de les traduire en règles applicatives concrètes : bornes de validation Laravel/Nova sur le titre, le contenu et le lien, ainsi qu’ajout d’exemples de placeholders dans les aides de saisie pour standardiser la rédaction.

En parallèle, un défaut d’encodage a été isolé sur l’intégration XLProg. La correction a été appliquée sans rupture de contrat côté client legacy : conservation du mode de sortie existant (echo / exit), conversion UTF-8 vers ISO-8859-1, et absence volontaire de nouveau header HTTP pour éviter toute régression. Cet arbitrage privilégie la robustesse d’intégration et s’inscrit dans le travail annuel de maintenance et d’évolution d’applications métiers interfacées.

Diagnostic et sécurisation des traitements fidélité

La journée a porté sur un point sensible d’une application de fidélité cliente développée en PHP / Laravel / Nova, avec un double objectif : qualifier l’origine d’anomalies de rattachement de comptes et sécuriser les traitements de relance associés aux campagnes d’expiration.

L’analyse des journaux de production a permis de rattacher les anomalies observées à un cas métier précis : des ventes enregistrées sans compte fidélité connecté, générant ensuite des incohérences dans le rattachement des comptes. Ce travail ne relevait pas d’un simple constat applicatif ; il visait à isoler un scénario réel de production, à objectiver son origine et à préparer une correction ou un encadrement plus fiable côté processus.

En parallèle, la configuration des tâches planifiées liées aux campagnes de relance avant expiration a été revue et validée. Des procédures de déclenchement manuel ont également été mises en place pour permettre des tests de bout en bout plus maîtrisés, sans dépendre uniquement des fenêtres d’exécution automatiques. Cela renforce la capacité à vérifier les enchaînements fonctionnels dans un contexte proche du réel.

Évolution ciblée de l’interface Nova

Sur le back-office, l’intervention a également porté sur l’amélioration de la lisibilité opérationnelle des notifications individuelles :

• ajout d’un filtrage personnalisé par code campagne, pour segmenter directement les notifications dans l’interface d’administration ;
• enrichissement de la vue avec l’identification du type d’appareil cible (Android / iOS).

Ce second point a été implémenté en exploitant dynamiquement les payloads JSON OneSignal, afin d’extraire l’information utile sans modification du schéma de base de données. L’arbitrage est notable : apporter une visibilité métier supplémentaire tout en préservant la structure existante de l’application.

Dans la continuité des évolutions menées ce mois sur des applications métiers Laravel / Nova, cette séquence illustre un travail de consolidation pragmatique : partir des incidents observés, fiabiliser les traitements planifiés et enrichir le back-office avec des informations immédiatement exploitables par les équipes métier.

La journée a porté sur la mise en place de la nouvelle campagne de bon d’anniversaire fidélité, en couvrant l’ensemble de la chaîne : cadrage métier, paramétrage back-office, logique applicative, automatisation d’exécution et tests de validation en local.

Les règles de gestion ont été consolidées de façon à rendre le dispositif exploitable sans ambiguïté fonctionnelle :

• date de référence basée sur la création du compte ;
• fenêtre de rattrapage de 7 jours pour absorber un éventuel incident d’automatisation ;
• traitement explicite du 29 février vers le 28 février les années non bissextiles ;
• éligibilité limitée aux comptes créés depuis plus d’un an ;
• mécanisme anti-doublon pour éviter tout renvoi d’un bon déjà traité ;

Intégration applicative et automatisation

Au niveau produit, un nouveau type de campagne « Bon d’anniversaire Fidélité » a été ajouté dans le back-office avec ses paramètres dédiés de montant et de durée. La logique de génération automatique des bons a ensuite été branchée sur le système existant, avec réutilisation du circuit de notification « nouveau bon » plutôt que création d’un flux parallèle.

L’exécution a été industrialisée via une commande Artisan dédiée, intégrée au scheduler Laravel. La gestion des notifications push a également été durcie avec trois modes opératoires distincts : envoi réel, simple contrôle OneSignal, ou désactivation complète. Le mode prudent a été retenu par défaut afin de sécuriser la phase de mise en service.

Ce travail s’inscrit dans la continuité des évolutions menées ce mois-ci sur l’application de fidélité : au-delà d’une fonctionnalité ponctuelle, il renforce un socle Laravel/Nova orienté campagnes pilotables, automatisations fiables et exploitation maîtrisée.

Cadrage du nouveau type de campagne

La journée a porté sur une évolution structurante de l’application de fidélité : l’introduction d’un type Notification nouveau bon conçu non comme un mécanisme de création de coupon, mais comme un levier métier d’autorisation d’envoi lors de la création d’un bon. Cet arbitrage a permis de sortir d’un traitement ad hoc historiquement centré sur le cas de bienvenue, au profit d’une logique plus générique et plus cohérente avec le cycle réel des coupons.

Déclenchement centralisé et déduplication

La notification a été repositionnée au bon endroit dans la chaîne technique, directement dans le cycle de création des coupons via un hook modèle. L’objectif était de supprimer les appels dispersés selon les flux de génération, source classique d’oublis et d’écarts de comportement. Dans le même mouvement, les identifiants techniques ont été harmonisés autour d’un campaign_code et d’un event_key cohérents, et la déduplication des rappels d’expiration a été revue pour reposer uniquement sur l’identifiant du bon. Ce travail améliore la lisibilité des déclenchements, la robustesse fonctionnelle et la prévisibilité des envois.

Mise à niveau de Nova et réduction de la fragilité

Le back-office Nova a été aligné avec cette évolution :

• intégration complète du nouveau type dans le formulaire d’administration ;
• ajout d’un texte explicatif dédié ;
• ajustement des règles de saisie et d’affichage dynamique ;
• correction du masquage des champs non pertinents selon les types Bienvenue, Rappel expiration et Notification nouveau bon.

Au-delà du correctif visible, le point important est la refactorisation de la logique de visibilité et de validation. Les listes de types répétées et les duplications entre hide, dependsOn, showOnCreating et showOnUpdating ont été supprimées au profit de constantes et helpers centralisés. Le résultat est un back-office plus lisible, moins fragile et mieux préparé aux prochaines évolutions fonctionnelles.

Dans la continuité du chantier mensuel d’évolution d’applications Laravel / Nova sur mesure, cette intervention renforce à la fois la qualité d’exécution métier et la maintenabilité du socle applicatif.

Mise en production d’un déclenchement maîtrisé

Travail de fond sur l’automatisation des rappels d’expiration de coupons de fidélité, avec un choix d’architecture volontairement aligné sur le fonctionnement standard de l’application : exécution centralisée via le scheduler Laravel, horaire configurable et ciblage des coupons expirant dans une fenêtre cohérente avec le délai défini par campagne. L’enjeu n’était pas seulement d’exécuter un rappel, mais de rendre le déclenchement lisible, maintenable et compatible avec l’exploitation courante de l’application.

Sécurisation du pipeline de notification

La journée a surtout permis de fiabiliser le cycle de vie complet des notifications :

• renseignement systématique des dates de traitement, y compris en cas d’échec ;
• ajout d’une date planifiée dès la création pour améliorer la traçabilité opérationnelle ;
• prévention des doublons par clé d’événement dédiée ;
• validation du comportement lors des relances du traitement.

Cette consolidation renforce la robustesse du dispositif dans une logique plus large d’évolution applicative continue sur un socle Laravel / Nova interfacé avec des systèmes tiers.

Tests non destructifs en environnement de développement

Un point sensible a été traité sur la validation des notifications push sans exposition à un envoi réel. Un mode de contrôle technique a été mis en place pour vérifier, en environnement de développement, la présence de l’external_id et l’état des souscriptions OneSignal, avec distinction explicite entre trois cas : identifiant absent, absence de souscription push, push désactivé.

Ce dispositif a permis une validation bout en bout sur des notifications réelles, tout en évitant un comportement intrusif ou non maîtrisé. C’est un apport concret en matière de qualité de test et de sécurité d’exploitation.

Renforcement des garde-fous métier et de l’interface

En complément, plusieurs corrections ont consolidé l’administration fonctionnelle :

• nettoyage de l’affichage des dates dans Nova pour supprimer des informations de fuseau horaire inutiles ;
• suppression d’une duplication de colonne ;
• ajout d’un contrôle bloquant empêchant le chevauchement de campagnes de même type sur une même période ;
• correction de la signature technique de cette validation pour rester compatible avec le framework d’administration.

Au-delà du correctif ponctuel, la journée s’inscrit dans une dynamique de maintenance évolutive exigeante : industrialiser sans alourdir, fiabiliser sans déroger aux standards applicatifs, et renforcer les contrôles là où ils produisent un effet direct sur l’exploitation métier.

Extension fonctionnelle maîtrisée

Évolution ciblée de l’application de fidélité pour introduire un nouveau type de campagne Bienvenue, avec ses paramètres dédiés et la migration associée. Le travail n’a pas été limité au modèle de données : l’administration Nova a été reprise pour rendre ce nouveau cas réellement exploitable en production, avec un ordonnancement de champs plus lisible, des affichages conditionnels par type et des aides contextuelles alignées sur l’usage métier. La validation a inclus le contrôle de l’état des migrations et l’absence de régression sur les რესsources Nova modifiées.

Automatisation distincte du flux historique

Un arbitrage d’architecture a été posé pour traiter le bon de bienvenue dans une logique dédiée, plutôt que d’alourdir le flux existant. Cette séparation permet de conserver un comportement plus lisible et plus maîtrisable dans une application métier déjà interfacée avec son écosystème. Concrètement :

• détection d’une campagne Bienvenue active ;
• création automatique du coupon à l’ouverture d’un compte fidélité ;
• alimentation des paramètres métier depuis la campagne en cours ;
• garde anti-doublon pour éviter les émissions multiples.

Ce choix s’inscrit dans la continuité des évolutions fonctionnelles menées ce mois sur les applications Laravel / Nova : privilégier des extensions nettes, testables et maintenables, plutôt qu’une accumulation de cas particuliers dans les chaînes existantes.

Fiabilisation de la chaîne de notification

La journée a également permis de fermer la boucle côté mobile avec l’ajout d’une notification OneSignal individuelle déclenchée après création du bon, planifiée avec lien profond vers l’espace des bons du client. Au-delà de l’intégration, le point clé a été le diagnostic de la chaîne d’exécution : validation du scheduler, identification du driver de queue effectivement utilisé (database), puis lancement d’un worker pour résorber et traiter les jobs en attente.

Pour sécuriser les essais fonctionnels, un routage temporaire de la notification Welcome vers un External ID OneSignal figé a été mis en place. Cette approche a permis de tester le chaînage complet de façon déterministe, depuis l’événement métier jusqu’à la réception mobile. L’ensemble constitue une évolution concrète de l’application : plus qu’une nouvelle campagne, une mécanique de bienvenue désormais cohérente, administrable et vérifiée de bout en bout.

Structuration d’un flux push distinct du legacy

Dans la continuité des évolutions engagées ce mois-ci sur l’application de fidélité client web et mobile, la journée a porté sur la mise en place d’un socle de notifications individuelles séparé du dispositif global existant. L’arbitrage principal a consisté à préserver le système legacy tout en ouvrant un nouveau flux relationnel plus finement pilotable.

• création d’une table dédiée individual_notifications
• définition du modèle associé avec statuts d’envoi, traçabilité provider, planification et support de file d’attente
• validation du schéma et exécution locale de la migration
• structuration pour gérer données JSON et horodatages métier

Pilotage back-office exploitable

Le travail ne s’est pas limité au modèle technique : il a également porté sur la mise en capacité opérationnelle du back-office Laravel Nova.

• création d’une ressource Nova dédiée aux notifications individuelles
• intégration de l’historique des envois dans la fiche utilisateur
• exposition ciblée des champs utiles à l’exploitation, avec séparation claire entre saisie métier et données techniques en lecture seule
• clarification de la navigation pour distinguer sans ambiguïté notifications globales et notifications individuelles

Fiabilisation du cycle d’envoi OneSignal

Un point significatif de la journée a concerné la fiabilité réelle du protocole d’envoi. Le service a été étendu pour cibler un utilisateur via son identifiant fidélité et piloter l’ensemble du cycle de vie (pending, queued, sent, failed, skipped).

Le diagnostic d’un faux positif d’envoi — réponse OneSignal sans identifiant exploitable mais interprétée à tort comme un succès — a conduit à corriger la logique de marquage afin d’éviter tout sent erroné. La validation finale a confirmé un envoi effectif avec retour provider exploitable.

Passage à l’asynchrone et replanification sans doublon

La chaîne a ensuite été durcie par le passage en traitement asynchrone maîtrisé : job dédié, action Nova de mise en file, commande de mise en queue des notifications planifiées et exécution via worker Laravel. Une correction a été apportée sur le respect de la date planifiée afin d’éviter les départs immédiats non souhaités.

Enfin, un mécanisme de replanification propre a été mis en place : en cas de changement de date d’envoi, le job en attente est supprimé puis recréé, ce qui sécurise le flux contre l’accumulation et les doublons. Ce type d’arbitrage s’inscrit dans une dynamique annuelle de maintenance et d’évolution d’applications métiers avec une exigence croissante de robustesse d’exécution.

Stabilisation applicative et diagnostic du flux

La journée a porté sur la remise sous contrôle d’une application Laravel de gestion de sondages de satisfaction, avec un double objectif : mieux comprendre les comportements inattendus du parcours de réponse et sécuriser la chaîne de livraison qui supporte l’exploitation.

Sur le plan applicatif, le travail a consisté à diagnostiquer les points où le flux de réponse au questionnaire pouvait diverger du comportement attendu. Cette revue ne s’est pas limitée au constat fonctionnel : elle a permis de localiser les zones sensibles du circuit web / backend afin de préparer des corrections plus sûres dans une architecture Laravel intégrant à la fois rendu web, API et administration Nova.

Reprise en main du pipeline GitHub Actions / Azure

Le sujet principal du jour a néanmoins été la fiabilisation du build et du déploiement :

• révision de la chaîne GitHub / Azure pour éliminer plusieurs causes concrètes d’instabilité ;
• correction du workflow principal afin d’utiliser des actions à jour et une version de PHP compatible avec le projet ;
• ajout de la gestion des identifiants Nova dans la CI pour éviter les échecs de récupération des dépendances privées ;
• verrouillage explicite de Laravel Nova dans la version cible, avec validation de l’état local pour garantir l’alignement entre développement et automatisation ;
• renforcement du déploiement Azure face aux conflits de publication de type 409, via des protections supplémentaires sur le verrou Kudu et la concurrence d’exécution ;
• nettoyage de la stratégie .gitignore pour mieux encadrer les composants Nova locaux ;
• vérification de composer.lock, avec confirmation qu’il doit bien rester versionné dans ce contexte pour préserver la reproductibilité.

Portée du travail

Au-delà des corrections ponctuelles, cette intervention s’inscrit dans une continuité plus large de maintenance et d’évolution d’applications métiers : remettre un socle de livraison en cohérence avec les dépendances réelles du projet, réduire les causes de dérive entre local, CI et production, et restaurer un niveau de prévisibilité suffisant pour reprendre les corrections fonctionnelles sur des bases propres.

Le résultat du jour est sobre mais structurant : pipeline plus robuste, versionnement mieux maîtrisé, dépendances Nova sécurisées et principaux blocages de build/deploy traités.

Remise à niveau ciblée d’un applicatif métier en production

Intervention de consolidation sur une application Laravel / Nova déjà en exploitation, dans une logique de continuité avec les travaux menés cette année sur des socles techniques plus robustes, gouvernables et durables. L’enjeu du jour n’était pas de “mettre à jour pour mettre à jour”, mais de restaurer un niveau de confiance acceptable sur un périmètre réellement exposé : sécurité, stabilité d’exécution et maintenabilité du système.

Sécurisation utile et réduction de dette

Le travail a porté sur la montée de version du socle technique, la revue des dépendances et l’assainissement de la chaîne de build frontend afin d’éliminer les fragilités les plus structurantes.

• validation d’un état de production sans vulnérabilité détectée sur les dépendances runtime ;
• isolement des alertes résiduelles sur l’outillage de développement, sans exposition directe en exploitation ;
• modernisation de la chaîne frontend vers un ensemble plus pérenne et plus lisible ;
• réduction de dette technique accumulée autour des scripts, outils et composants périphériques.

Correction des régressions et fiabilisation métier

La remise à niveau a également nécessité un traitement des régressions post-upgrade, avec un focus sur les traitements sensibles, notamment la génération documentaire. L’intervention a consisté à rétablir un comportement fiable sur les fonctions métier les plus critiques, plutôt qu’à empiler des correctifs ponctuels.

En parallèle, l’interface d’administration Nova a été rationalisée pour retrouver une cohérence opérationnelle :

• navigation clarifiée ;
• interface mieux alignée avec les usages réels ;
• amélioration de la qualité de localisation et de la lisibilité générale.

Une maintenance traitée comme un chantier de consolidation

Cette journée prolonge le fil annuel de maintenance, support et évolution d’applications métiers clients avec une approche identique à celle appliquée sur d’autres chantiers plus structurants : partir du réel, diagnostiquer les points de rupture, arbitrer ce qui doit être modernisé, puis stabiliser l’existant sans sur-promesse.

Le résultat est une application plus propre, plus fiable et mieux préparée pour ses évolutions futures, avec un socle technique redevenu exploitable dans de bonnes conditions.

Cadrage du sujet du jour

La journée a été consacrée à l’arbitrage d’une stratégie de synthèse de textes et conversations très longues pour un usage exploitable dans une chaîne d’IA documentaire et d’assistance d’entreprise. Le travail ne s’est pas limité à comparer des modèles : il a consisté à structurer une approche réaliste, soutenable en coût, et compatible avec une logique de mémoire durable.

Choix de modèles selon l’usage

Un premier tri a permis de distinguer clairement les modèles selon leur rôle :

• Pour la qualité de synthèse sur très gros volumes :
  • Gemini 2.5 Pro pour sa grande fenêtre de contexte
  • GPT-5.2 Thinking / GPT-5.4 pour la fidélité, la structuration et la qualité de restitution
  • Claude Opus 4.6 pour la lisibilité et la nuance rédactionnelle
• Pour une extraction économique :
  • Gemini 2.5 Flash-Lite comme option la plus frugale
  • Gemini 2.5 Flash comme compromis coût / performance
  • DeepSeek V3.x et Qwen 2.5 72B retenus comme alternatives crédibles pour l’extraction structurée par blocs

Décision d’architecture

L’arbitrage principal du jour est le suivant : éviter le résumé global monolithique au profit d’un pipeline en plusieurs étapes :

1. découpage en blocs,
2. extraction structurée par bloc,
3. fusion et déduplication,
4. passe finale de consolidation.

La consigne a été reformulée en conséquence : demander au modèle une extraction d’idées fortes plutôt qu’un résumé narratif. Les catégories retenues sont notamment : idées principales, décisions, contraintes, faits clés, actions et questions ouvertes, avec une sortie JSON stricte.

Maîtrise des coûts et mémoire utile

Un second axe important a porté sur la réduction des coûts de mémorisation continue :

• ne pas résumer systématiquement tous les échanges ;
• filtrer d’abord les messages pour ne conserver que les éléments durables ;
• privilégier l’extraction des messages utilisateur ;
• déclencher la mémoire sur événements significatifs ;
• séparer contexte récent brut, mémoire durable compacte et archives complètes accessibles via RAG.

Le pipeline cible repose donc sur une chaîne sobre : règles locales → fragments candidats → déduplication → appel LLM minimal → stockage atomique.

Prolongement du chantier

Ce travail prolonge directement la consolidation d’OpenWebUI et de la chaîne documentaire du mois : l’enjeu n’est plus seulement de disposer d’une interface ou d’un RAG, mais de fiabiliser la manière dont l’information conversationnelle utile est extraite, capitalisée et réutilisée. À l’échelle annuelle, cela renforce la construction d’un socle d’IA d’entreprise souverain, capable de transformer des échanges bruts en connaissance exploitable, sans dérive de coût ni perte de contrôle.

Données OpenWebUI rendues exploitables

La journée a surtout porté sur la mise sous contrôle des données internes d’OpenWebUI afin de mieux piloter une chaîne documentaire exploitable en environnement self-hosted. Un premier bloc a consisté à clarifier la structure JSON stockée dans chat et à produire des requêtes SQL réellement utilisables pour :

• extraire les messages depuis chat->'messages'
• reconstruire des paires question/réponse
• générer un transcript complet par conversation
• ajouter des indicateurs de longueur, de taille en octets et un filtre sur les dernières 24h

Le travail a aussi permis de fiabiliser plusieurs détails techniques importants : usage de json_array_elements(...) car la colonne est en json, conversion des timestamps Unix via to_timestamp(...) sur chat_message.updated_at, et affichage propre du contenu JSON avec content #>> '{}'.

Contrôle de cohérence des fichiers et chunks

Un second axe important a concerné la détection d’incohérences entre document_chunk, file et knowledge. L’analyse a permis de distinguer clairement :

• les fichiers rattachés à une knowledge base via meta.data.knowledge_id
• les collections techniques de type file-<uuid>
• les cas potentiellement orphelins ou incomplets

Dans un contexte multi-bases, le choix pragmatique retenu a été de faire la comparaison dans n8n plutôt que de forcer un rapprochement SQL local. Les tests menés montrent qu’il n’y a vraisemblablement pas d’orphelins sur le critère document_chunk.vmetadata->>'file_id' vs file.id, ce qui réoriente le diagnostic vers d’autres causes possibles : métadonnées incomplètes, chunks sans file_id ou incohérences applicatives.

n8n et mémoire OpenWebUI : vers une exploitation plus robuste

La journée a également consolidé la couche d’orchestration avec n8n : agrégation SQL avant comparaison, regroupement d’items en JSON unique, production d’un results_text propre pour les prompts, parsing de réponses LLM JSON et synchronisation de branches via Merge en mode Combine.

En parallèle, le fonctionnement de la mémoire OpenWebUI a été clarifié, notamment la distinction entre Memory, Notes et Knowledge. L’analyse du code de la fonction Auto Memory a mis en évidence plusieurs défauts structurels sérieux, conduisant à une conclusion nette : l’idée est pertinente, mais le code montré n’est pas suffisamment fiable pour un usage de production sans correction et instrumentation par logs.

Dans la continuité des travaux mensuels d’optimisation d’OpenWebUI et de consolidation d’une IA documentaire souveraine, cette journée renforce la trajectoire annuelle : faire d’OpenWebUI une façade réellement maîtrisée, branchée sur des données vérifiables, des workflows traçables et une architecture documentaire gouvernable.

Conception et structuration d’un socle de publication dédié à une timeline technique multilingue, avec un modèle de données capable de porter des cartes datées, un contenu éditorial et une catégorisation bilingue. Le travail du jour a porté sur l’architecture des niveaux de lecture quotidien, mensuel et annuel, afin de produire un rendu cohérent à la fois en détail et en synthèse.

La mise en œuvre s’est appuyée sur une base PostgreSQL Azure structurée pour séparer clairement les contenus, les regroupements temporels et le référentiel de tags. Le schéma a intégré des contrôles de cohérence sur les dates, des identifiants adaptés à un usage éditorial et une gestion automatique des timestamps pour fiabiliser les mises à jour.

Un référentiel de tags français / anglais a également été normalisé pour homogénéiser la qualification des contenus et préparer une exploitation propre côté interface. Ce travail s’inscrit dans la dynamique du mois visant à transformer les réalisations techniques en contenus publiables, et prolonge la trajectoire annuelle de structuration d’une pile maîtrisée, durable et valorisable dans une logique de produit professionnel.

Le travail s'est poursuivi autour de la récupération documentaire SharePoint, avec une approche plus orientée usages réels. La question n'était plus seulement de synchroniser, mais aussi de simplifier l'accès aux contenus et leur exploitation dans des workflows. Les recherches sur les packages, connecteurs et stratégies de récupération ont prolongé les bases posées auparavant. Le sujet reste central pour alimenter une base de connaissance exploitable. Cette continuité confirme l'importance stratégique de Microsoft 365 dans l'architecture.

En mars, les travaux s'orientent vers la stabilisation et l'assemblage cohérent des briques déjà explorées. Le focus s'est porté sur l'exploitation pratique d'OpenWebUI, PostgreSQL, les embeddings et les traitements documentaires. L'objectif n'était plus seulement de comparer, mais de faire tenir l'ensemble dans un cadre fiable. Cela inclut les performances, la cohérence fonctionnelle et les limites des composants choisis. Le mois est consacré à une phase de consolidation active.

Mars montre aussi une volonté plus marquée de transformer les travaux réalisés en contenus publiables. La réflexion autour d'une timeline, d'un portfolio technique et d'une mise en récit des réalisations devient plus visible. L'enjeu est de présenter les sujets sous forme de réalisations, décisions, tests et intégrations concrètes. Le technique commence ici à être retravaillé comme actif de communication professionnelle.

Le mois a vu émerger plusieurs sujets pratiques autour d'OpenWebUI : qualité des réponses, prompt système, analytics, branding et intégration. Le travail a porté sur l'amélioration du comportement réel de l'outil en situation de production professionnelle. Cela montre un déplacement progressif vers les questions d'expérience, de pilotage et de valeur perçue. L'outil n'est plus seulement observé comme composant technique, mais aussi comme produit utilisableen contexte professionnel d'entreprise.

Renforcement du lien entre les choix d'architecture et une offre lisible orientée entreprise. Le sujet couvre l'hébergement maîtrisé, la confidentialité, l'IA documentaire et la valeur métier des assistants construits. Les éléments techniques sont progressivement rattachés à une proposition de service plus claire. On n'est plus seulement dans l'expérimentation technique, mais dans la transformation en offre crédible professionnelle d'entreprise. Cela donne au mois de mars une dimension plus produit et plus stratégique.

Le mois a aussi été marqué par des sujets d'exploitation plus techniques sur Azure, PostgreSQL et l'environnement de déploiement. Les travaux ont porté sur la base de données, les extensions, les migrations, le proxy inverse et les services managés pertinents. Les arbitrages coût, simplicité et robustesse ont pris une place centrale. L'objectif était de rendre l'écosystème plus stable et plus cohérent avec les usages visés. Cette consolidation a servi d'appui aux expérimentations IA et documentaires professionnelles.

Les expérimentations se sont heurtées à des contraintes très concrètes de CPU, mémoire et temps de traitement. Le travail a consisté à tester ce qui tenait réellement sur la VM Windows server 2025 en matière d'embeddings, de modèles locaux et de charge globale. Les options trop lourdes ont été reconsidérées à l'aune de la performance observée. La viabilité self-hosted est devenue un critère aussi important que la qualité théorique. Cela a conduit à des choix plus réalistes et plus exploitables, notamment le passage à un hébergement sur VM Linux Ubuntu dans Azure gérant mieux les ressources (CPU, RAM et disques).

Au lieu d'évaluer OpenWebUI de manière abstraite, le travail a porté sur ses comportements réels dans un contexte de production professionnelle. Les sujets abordés incluent la gestion des collections, l'ajout de fichiers, l'usage des parsers externes et le couplage avec des services RAG. Les limites fonctionnelles ont été mieux identifiées. Cela a permis de distinguer ce qui devait rester dans l'outil et ce qui devait être déplacé à l'extérieur. Le rôle d'OpenWebUI s'est affiné comme couche d'interface plutôt que comme solution totale.

Le mois a marqué une transition entre architecture cible et mise en œuvre concrète. Le travail s'est concentré sur la manière de brancher un retrieval externe, de maîtriser l'index et de fiabiliser le comportement réel du système. Les questions de suppression, mise à jour, reconstruction d'index et cohérence des résultats ont pris plus d'importance. L'enjeu était de sortir d'un simple prototype pour aller vers un flux exploitable. Cette phase a renforcé la dimension opérationnelle du projet documentaire d'entreprise.

Approfondissement d'une architecture où l'indexation et la recherche sont gérées hors de l'interface de chat. Le travail a porté sur les bénéfices d'un contrôle plus fin sur les documents, les vecteurs et le cycle de vie des contenus. Cela a ouvert la voie à des fonctions avancées comme le reranking ou des logiques de recherche hybrides. L'approche permettait aussi de mieux séparer les responsabilités entre interface, moteur de recherche et pipeline d'ingestion. Cette orientation a clarifié la structure globale du système d'IA d'entreprise.

Évaluation des compromis entre qualité d'indexation, coût CPU, taille des vecteurs et faisabilité sur VM. Plusieurs approches ont été comparées pour l'extraction documentaire et les embeddings, avec une attention particulière à la stabilité. Le sujet n'était pas seulement théorique : il fallait identifier ce qui pouvait réellement tenir dans l'environnement. Cette phase a permis d'écarter certaines options trop lourdes. Elle a aussi préparé les choix plus pragmatiques des évolutions à venir.

Le travail a inclus la logique de synchronisation, le suivi des changements et la préparation d'une alimentation continue du moteur documentaire. Les delta queries et la gestion des bibliothèques ont été au cœur des réflexions. L'objectif était de bâtir un flux robuste entre Microsoft 365 et la base de connaissance. Ce chantier s'inscrit dans une logique d'orchestration documentaire professionnelle industrialisable.

Consolidation de n8n comme couche d'automatisation pour piloter les flux documentaires et les appels de services. Les travaux ont porté sur la structuration de sous-workflows, la circulation de la configuration et la composition de JSON techniques. L'approche visait à rendre les traitements réutilisables et lisibles. Cela a permis de préparer une industrialisation progressive des pipelines. n8n a commencé à prendre une place centrale dans l'assemblage des briques.

Définition d'un socle documentaire capable d'ingérer, indexer et restituer des contenus d'entreprise de façon exploitable. Le travail a porté sur la chaîne complète : extraction, découpage, embeddings, indexation vectorielle et retrieval. Plusieurs options ont été comparées pour garder un bon niveau de contrôle technique sans alourdir l'exploitation. L'objectif était de poser une architecture lisible, modulaire et durable. Cette phase a servi de base aux arbitrages réalisés les semaines suivantes.

Exploration du rôle exact d'OpenWebUI dans une architecture documentaire plus large. Le sujet n'est pas seulement l'interface, mais aussi la frontière entre ce qui devait rester natif et ce qui devait être externalisé. Les réflexions ont porté sur les collections, les embeddings, les parseurs et le comportement global du système. L'enjeu est de ne pas subir les limites de l'outil sur des cas plus ambitieux. Ce travail a préparé une approche plus découplée entre UI, indexation et recherche.