Coclico

Historique des revisions

1. Resume executif

Coclico est une plateforme de gestion systeme Windows de classe entreprise, concue pour operer integralement en local, sans aucune connexion vers un service cloud. La version 1.0.4 represente l'aboutissement de quatre phases majeures de developpement, couvrant la gestion des processus, l'automatisation par chaines visuelles, le nettoyage systeme avance, et un noyau autonome pilote par intelligence artificielle locale.

L'application repose sur le framework .NET 10 avec le langage C# en mode preview, une interface graphique construite sur WPF-UI 4.2 (Fluent Design), et un moteur d'inference IA local base sur LLamaSharp 0.26. L'ensemble du traitement, y compris les decisions d'optimisation prises par le modele de langage, s'execute exclusivement sur la machine de l'utilisateur.

Le noyau autonome constitue la particularite principale de Coclico. Il implemente une boucle d'observation, d'analyse et d'action en trois etapes pipelinisees. Le composant OptimizationEngine collecte les metriques systeme toutes les 30 secondes, les soumet au modele d'inference pour decision, puis execute les actions validees avec creation systematique d'un point de restauration. En parallele, le composant SourceAnalyzer analyse le code source C# a l'aide de Roslyn pour identifier les hotspots de complexite, tandis que le Clone Numerique (StateValidator) valide que toute modification proposee par l'IA ne degrade pas les metriques de qualite logicielle.

La version 1.0.4 integre les corrections issues d'un audit expert complet, un refactoring sur six axes structurels (elimination du code mort, injection de dependances exclusive, decouplage par interfaces, algorithmes statistiques avances), ainsi qu'un site web multi-langue deploye sur GitHub Pages.

Chiffres cles de l'application :

• 8 modules fonctionnels operationnels
• 28 types de noeuds d'automatisation dans les Flow Chains
• 10 operateurs conditionnels pour la logique de branchement
• 18 operations natives P/Invoke pour le nettoyage memoire
• 10 langues supportees dans l'interface utilisateur
• Inference IA 100% locale -- zero donnee envoyee a l'exterieur
• Pipeline d'optimisation autonome a 3 etages avec canaux bornes
• Analyse statique Roslyn avec 5 metriques de complexite par methode

2. Presentation generale

2.1 Philosophie du projet

Coclico incarne une vision d'autonomie numerique totale. L'objectif est de fournir a l'utilisateur un outil capable de gerer, optimiser et auditer son systeme Windows sans jamais deleguer une seule operation a un service exterieur. Cette philosophie se materialise par le principe architectural Zero Cloud : toute l'inference IA, toute la telemetrie, tout le stockage de donnees s'executent exclusivement sur la machine locale.

La trajectoire de developpement suit une progression methodique vers l'autonomie. Les premieres phases ont etabli les fondations (telemetrie, gestion de la qualite de service, mecanisme de restauration). Les phases intermediaires ont introduit l'intelligence artificielle locale avec un double contexte d'execution isole. Les phases actuelles visent la capacite d'auto-amelioration du code source par analyse statique et patching automatique, le tout supervise par un clone numerique qui garantit la non-regression de la qualite.

2.2 Perimetre fonctionnel

Le perimetre fonctionnel de Coclico couvre huit domaines principaux :

2.3 Public cible

Coclico s'adresse a trois profils d'utilisateurs complementaires. Les administrateurs systeme y trouvent un outil de supervision et de maintenance centralise. Les developpeurs beneficient des capacites d'analyse de code et d'auto-optimisation du noyau autonome. Les utilisateurs avances exploitent les Flow Chains pour automatiser leurs taches quotidiennes sans ecrire de code.

3. Architecture technique detaillee

3.1 Pile technologique

Optimisations de compilation

Le fichier projet (Coclico.csproj) active les optimisations suivantes au niveau du runtime :

3.2 Cycle de vie de l'application

Le demarrage de Coclico suit une sequence rigoureusement ordonnee, implementee dans App.xaml.cs. Chaque etape est condiditonnelle et journalisee.

Sequence de demarrage (App.OnStartup)

1. Verification d'elevation -- Le processus verifie s'il s'execute avec les privileges administrateur via WindowsPrincipal.IsInRole(WindowsBuiltInRole.Administrator). Si ce n'est pas le cas, une fenetre AdminPromptWindow propose a l'utilisateur de redemarrer avec elevation UAC. En cas de refus, l'application s'arrete.
2. Configuration du runtime -- Le mode de rendu est fixe a RenderMode.Default, le pool de threads est calibre sur le nombre de coeurs processeur (Environment.ProcessorCount), le GC est place en mode SustainedLowLatency, et le taux d'images des animations WPF est fixe a 60 FPS.
3. Construction du conteneur DI -- ServiceContainer.Build() est appele avec une lambda de configuration qui enregistre l'ensemble des services. La validation est activee (ValidateOnBuild = true), ce qui provoque une erreur immediate si une dependance est manquante.
4. Affichage du Splash Screen -- SplashWindow est affichee pendant l'initialisation des services en arriere-plan (RunStartupAsync).
5. Elagage de l'audit -- Le service IAuditLog execute un nettoyage des entrees depassant la duree de retention configuree (par defaut : 90 jours).
6. Configuration du premier lancement -- Si Settings.FirstRun est vrai, la fenetre LauncherWindow s'affiche pour permettre la configuration du mode de demarrage (Normal, Minimise, Tray), du demarrage automatique avec Windows et de la reduction dans la zone de notification.
7. Creation de la fenetre principale -- MainWindow est instanciee et affichee selon le mode configure.
8. Application du theme -- ThemeService.ApplyCurrentSettings() applique la couleur d'accent, l'opacite des cartes et le mode sombre/clair.
9. Nettoyage memoire initial -- MemoryCleanerService.TrimSelfWorkingSet() est execute en arriere-plan pour reduire l'empreinte memoire du processus.
10. Demarrage du service de mise a jour -- UpdateCheckService est initialise et verifie les mises a jour toutes les 5 minutes.

Sequence d'arret (App.OnExit)

L'arret procede au nettoyage ordonne des ressources. Chaque etape est protegee par un bloc try/catch independant pour garantir la robustesse :

1. Arret et liberation de ResourceGuardService
2. Liberation de ThemeService
3. Liberation de IAiService (decharge le modele LLM de la memoire)
4. Liberation de ProcessWatcherService
5. Liberation de NetworkMonitorService
6. Flush de la telemetrie (IDynamicTracer.FlushToDisk)
7. Arret du conteneur DI (ServiceContainer.Shutdown), qui appelle Log.CloseAndFlush() pour Serilog

3.3 Injection de dependances

Le conteneur de dependances est encapsule dans la classe statique ServiceContainer, un wrapper thread-safe autour de IServiceProvider utilisant Lazy<T> avec LazyThreadSafetyMode.ExecutionAndPublication.

API du conteneur

Registrations des services

Les services sont enregistres selon trois categories :

Services avec contrat d'interface (Singletons) :

Services concrets (Singletons) : SettingsService, InstalledProgramsService, ProfileService, ProcessWatcherService, WorkflowService, ThemeService, LocalizationService, ResourceGuardService, NetworkMonitorService, KeyboardShortcutsService, StartupService, FeatureExecutionEngine.

Services transitoires : CleaningService, InstallerService, StartupHealthService, UserAccountService.

3.4 Structure MVVM

L'application suit le patron Model-View-ViewModel avec une separation stricte des responsabilites :

Les mises a jour de l'interface utilisateur depuis les services de fond respectent la contrainte WPF de thread-affinity via Dispatcher.InvokeAsync. Aucun service n'attend de maniere synchrone une reponse du modele LLM depuis le thread UI.

3.5 Optimisations du runtime

Au demarrage, l'application configure le runtime pour minimiser les latences :

• Thread pool -- Le nombre minimum de threads est fixe a Environment.ProcessorCount pour eviter les delais de montee en charge.
• GC -- Le mode SustainedLowLatency reduit les pauses de collection pendant les operations interactives.
• Animations -- Le frame rate WPF est fixe a 60 FPS via Timeline.DesiredFrameRateProperty.
• Rendu -- Le mode de rendu est RenderMode.Default pour compatibilite maximale avec l'acceleration materielle.

4. Modules fonctionnels

4.1 Tableau de Bord

Le Tableau de Bord est la page d'accueil de Coclico. Il affiche en temps reel, avec un intervalle de rafraichissement de 3 secondes, les metriques systeme essentielles :

L'implementation utilise DashboardViewModel qui met a jour les proprietes liees via le Dispatcher pour respecter le modele de threading WPF.

4.2 Applications

Le module Applications fournit une bibliotheque exhaustive de tous les logiciels et jeux installes sur le systeme. La detection s'appuie sur de multiples sources :

Fonctionnalites avancees :

• Double-clic pour lancer directement une application
• Renommage personnalise (sauvegarde dans custom_apps_data.json)
• Changement de categorie personnalise
• Ajout manuel d'un executif (.exe)
• Filtrage et recherche instantanee
• Cache de 6 heures via ICacheService pour des performances optimales

Le service InstalledProgramsService utilise des SearchValues<string> (.NET 8+) et des FrozenSet<string> pour filtrer efficacement les utilitaires systeme et drivers de la liste affichee. Des expressions regulieres generees a la compilation ([GeneratedRegex]) optimisent le parsing des manifests.

4.3 Flow Chains

Les Flow Chains constituent le moteur d'automatisation visuelle de Coclico. L'utilisateur compose des chaines de taches par glisser-deposer dans un editeur graphique a noeuds connectes.

Types de noeuds disponibles (28)

Operateurs conditionnels (10)

Gestion des erreurs par noeud

Chaque PipelineStep possede une propriete OnErrorAction qui determine le comportement en cas d'echec :

• ContinueNext (defaut) -- Passe au noeud suivant
• StopChain -- Arrete immediatement la chaine
• SkipToEnd -- Saute directement au noeud End

Les chaines sont persistees au format JSON dans %AppData%\Coclico\flow_chains.json. Un mecanisme de migration automatique (ApplyV2MigrationAsync) gere la transition vers le format v2. Les declencheurs supportes incluent les raccourcis clavier globaux (Ctrl+(Alt+)Touche) et les intervalles temporels configurables (minimum 10 secondes).

4.4 Installeur Rapide

L'Installeur Rapide fournit une interface graphique pour Windows Package Manager (Winget), permettant l'installation de logiciels en un clic sans recourir a la ligne de commande.

Categories de logiciels disponibles :

• Internet -- Navigateurs, clients VPN, clients de messagerie
• Runtimes -- .NET, Visual C++ Redistributables, Java Runtime
• Developpement -- IDE (Visual Studio, VS Code), Git, Docker, Node.js
• Gaming -- Plateformes de jeux (Steam, Epic, GOG)
• Creation -- Outils de design, montage video, audio
• Systeme -- Utilitaires systeme, archiveurs, lecteurs multimedia

La portee d'installation (Scope) est configurable entre Machine (tous les utilisateurs) et User (utilisateur courant) via les parametres de l'application.

4.5 Nettoyage Systeme

Le module de Nettoyage Systeme fournit un moteur de maintenance professionnel avec estimation prealable de l'espace recuperable. Le service CleaningService implemente deux niveaux de nettoyage :

Categories de nettoyage (10)

Le mode Deep Clean ajoute un nettoyage intensif couvrant les fichiers orphelins, les caches applicatifs etendus et les artefacts de mise a jour Windows. Le resultat de chaque operation est encapsule dans un objet CleaningResult contenant le nombre de fichiers supprimes, l'espace libere en octets, la duree d'execution et la liste des erreurs eventuelles.

4.6 Scanner

Le Scanner realise un audit complet de l'ensemble des applications installees. Pour chaque application detectee, il restitue :

• Nom de l'application
• Version installee
• Editeur
• Taille sur disque
• Chemin d'installation complet
• Source de detection (Registre, Steam, Epic, etc.)
• Date d'installation

Les resultats sont triables et filtrables en temps reel. Le ScannerViewModel orchestre l'analyse et presente les resultats dans une vue tabulaire avec possibilite d'export.

4.7 RAM Cleaner

Le module RAM Cleaner est le composant le plus profond du point de vue systeme. Il exploite 18 operations natives Windows via P/Invoke pour optimiser l'utilisation de la memoire vive.

Informations affichees

• RAM physique -- Utilisee / Totale (via GlobalMemoryStatusEx)
• Memoire virtuelle -- Commit Charge (Total PageFile - Available PageFile)
• Pagefile -- Taille totale et disponible

Operations P/Invoke natives

Chaque operation requiert l'acquisition prealable des privileges SeDebugPrivilege et SeIncreaseQuotaPrivilege via AdjustTokenPrivileges. Le mode automatique permet le declenchement sur intervalle de temps ou des qu'un seuil d'utilisation RAM est depasse.

4.8 Coclico AI

Coclico AI est l'assistant conversationnel integre. Il s'appuie sur le modele GGUF local et dispose d'une connaissance complete des 8 modules de l'application, des fonctionnalites transversales et des donnees utilisateur. L'assistant est capable de guider l'utilisateur etape par etape, de repondre dans la langue de l'utilisateur (detection automatique parmi 10 langues) et de s'appuyer sur la documentation interne via le systeme RAG. Le detail de l'architecture IA est presente dans la section 5.

5. Intelligence artificielle locale

5.1 Architecture LLamaSharp dual-executor

L'architecture IA de Coclico repose sur un design a double contexte d'execution isole, implemente dans AiChatService. Ce design garantit que les interactions utilisateur et les decisions du noyau autonome ne s'interferent jamais.

                    +------------------+
                    |  LLamaWeights    |
                    |  (modele GGUF)   |
                    +--------+---------+
                             |
               +-------------+-------------+
               |                           |
     +---------+---------+       +---------+---------+
     |  Chat Context     |       |  Engine Context   |
     |  (_chatCtx)       |       |  (_engineCtx)     |
     +-------------------+       +-------------------+
     | ContextSize: 2048 |       | ContextSize: 512  |
     | Threads: N-1 (max6)|      | Threads: N/2      |
     | BatchSize: 256    |       | BatchSize: 128    |
     | FlashAttention: ON|       | FlashAttention: ON|
     +--------+----------+       +--------+----------+
              |                            |
     +--------+----------+       +--------+----------+
     | InteractiveExecutor|      | InteractiveExecutor|
     +--------+----------+       +--------+----------+
              |                            |
     +--------+----------+       +--------+----------+
     | _chatSem (1,1)    |       | _engineSem (1,1)  |
     | Semaphore          |      | Semaphore          |
     +--------+----------+       +--------+----------+
              |                            |
     +--------+----------+       +--------+----------+
     | AiChatView        |       | OptimizationEngine |
     | (User-facing)     |       | (Background)       |
     +--------------------+      +--------------------+

Modele de concurrence

Chaque contexte possede son propre SemaphoreSlim(1, 1) qui garantit l'acces exclusif. Le pattern Immutable Context Swap est utilise pour les reinitialisation : Interlocked.Exchange remplace atomiquement le contexte tout en disposant l'ancien, sans bloquer les consommateurs en cours d'attente.

Strategie GPU / CPU

L'initialisation tente d'abord un chargement avec 8 couches GPU (GpuLayerCount = 8). En cas d'echec (materiel incompatible, drivers absents), le service bascule automatiquement sur le mode CPU pur (GpuLayerCount = 0). Le nombre de couches GPU actives est expose via la propriete ActiveGpuLayers.

Gestion de la memoire conversationnelle

Le service maintient une memoire a court terme de 4 echanges (configurable via MaxMemoryTurns). Apres 6 tours de conversation (AutoResetAfterTurns), le contexte est automatiquement reinitialise pour eviter la degradation de la qualite des reponses. La memoire recente est injectee dans le prompt sous forme de bloc structure :

[Memoire recente]
T1 U:"question1..." A:"reponse1..."
T2 U:"question2..." A:"reponse2..."

5.2 Liberation memoire automatique

Pour eviter que le modele LLM (estimee a environ 2,5 Go de RAM) ne reste charge indefiniment en memoire, un mecanisme de dechargement automatique est integre.

Le rechargement est transparent : toute nouvelle requete via SendMessageAsync ou SendSystemPromptAsync declenche automatiquement InitializeAsync si le modele n'est pas en memoire.

5.3 RAG integre

Coclico integre un systeme de Retrieval-Augmented Generation (RAG) implementee dans RagService. Ce systeme permet a l'assistant de s'appuyer sur la documentation interne stockee dans le repertoire resource/docs/.

Pipeline de traitement

1. Indexation -- Les fichiers Markdown sont decoupes en chunks base sur les en-tetes (#{1,3}). Chaque chunk d'au moins 40 caracteres est indexe.
2. Tokenisation -- Les textes sont tokenises avec elimination des mots vides (stopwords) et racinisation (stemming) via SimpleStemmer.
3. Calcul TF-IDF -- Chaque chunk recoit un vecteur TF-IDF normalise. La formule IDF utilisee est : log((N - df + 0.5) / (df + 0.5) + 1).
4. Recherche hybride -- Les requetes sont evaluees par une combinaison ponderee de deux scores :
   • BM25 (poids 0.6) avec parametres k1=1.5, b=0.75
   • Similarite cosinus TF-IDF (poids 0.4)
5. Extraction -- Les topK meilleurs chunks (defaut : 2) sont retournes avec une limite de 350 caracteres par chunk.

5.4 Parametres d'inference

Deux jeux de parametres d'inference distincts sont utilises selon le contexte d'execution :

Le contexte Engine utilise une temperature tres basse (0.1) et un TopK reduit (10) pour maximiser le determinisme des decisions d'optimisation systeme. Le contexte Chat utilise des valeurs plus elevees pour permettre des reponses plus naturelles et variees.

6. Noyau autonome

Le noyau autonome de Coclico implemente une boucle Observe-Analyze-Act-Validate decomposee en quatre services complementaires. Cette architecture est le coeur de la vision d'auto-gouvernance du systeme.

6.1 OptimizationEngine -- Pipeline 3 etapes

Le service OptimizationEngineService implemente un pipeline asynchrone a trois etapes connectees par des Channel<T> bornes. Ce design decouple la collecte des metriques, la prise de decision et l'execution des actions.

+------------------+    Channel<SystemMetrics>    +------------------+    Channel<string>    +------------------+
|  Stage 1         |  (Bounded, DropOldest, 1)    |  Stage 2         | (Bounded, DropOldest, 1) |  Stage 3         |
|  COLLECTE        | ---------------------------> |  DECISION        | ----------------------> |  EXECUTION       |
|                  |                              |                  |                         |                  |
| CollectMetrics() |                              | Cognitive (LLM)  |                         | ExtractAction()  |
| - CPU %          |                              | ou               |                         | - CreateSnapshot |
| - RAM Usage      |                              | Fallback (Rules) |                         | - SetPriority()  |
| - Top 5 procs    |                              |                  |                         | - Audit Log      |
| - Anomalies IF   |                              | + Audit Entry    |                         | - RCA Summary    |
+------------------+                              +------------------+                         +------------------+
      |                                                                                              |
      +--- Cycle: 30 secondes -----------------------------------------------------------------------+

Stage 1 : Collecte (Stage1CollectAsync)

Toutes les 30 secondes, cette etape collecte un snapshot complet de l'etat systeme :

Le detecteur d'anomalies IsolationForestDetector analyse les trois dimensions (CPU, RAM, DiskIO) et retourne un score d'anomalie. Le seuil est fixe a 0.65.

Stage 2 : Decision (Stage2DecideAsync)

Si le service IA est initialise, le prompt systeme est construit a partir des metriques et soumis au contexte Engine. Le modele repond exclusivement en JSON avec le format :

{
  "ProcessId": 1234,
  "ProcessName": "chrome",
  "TargetPriority": "BelowNormal",
  "Reason": "...",
  "RcaSummary": "analyse causale courte",
  "NoAction": false
}

Si le modele IA n'est pas disponible, un moteur de regles deterministes prend le relais. Le Adaptive Scorer calcule un score composite pondere (CPU: 0.4, RAM: 0.3, Disk: 0.2, History: 0.1) et declenche une action si le score depasse le seuil de 0.6. Les poids s'ajustent automatiquement en fonction de l'efficacite des actions passees.

Chaque decision est enregistree dans la piste d'audit avec le contexte IA complet (AiDecisionContext : prompt, reponse brute, mode de decision).

Stage 3 : Execution (Stage3ExecuteAsync)

L'action extraite de la reponse JSON est executee selon la sequence suivante :

1. Lecture de la priorite actuelle du processus cible via IResourceAllocator
2. Creation d'un snapshot de restauration via IRollbackService.CreateSnapshot()
3. Application du changement de priorite via IResourceAllocator.SetProcessPriority()
4. Enregistrement du resultat dans le journal et le rapport

Les processus critiques (system, smss, csrss, wininit, winlogon, lsass, services, svchost, explorer, coclico) sont proteges par une liste de blocage et ne peuvent jamais etre cibles par le moteur.

6.2 SourceAnalyzer -- Roslyn AST

Le service SourceAnalyzerService implemente une analyse statique complete du code source C# en utilisant l'API Roslyn (Microsoft.CodeAnalysis.CSharp). Pour chaque methode analysee, cinq metriques de qualite sont calculees.

Metriques calculees par methode

Classification de severite

La severite est rehaussee d'un cran si le nombre de lignes de la methode depasse 80. Les methodes classees "Low" avec moins de 20 lignes sont exclues du rapport pour reduire le bruit. Le rapport final (SourceAnalysisReport) est un record immutable contenant la liste triee des hotspots (par severite decroissante, puis par CC decroissant).

6.3 StateValidator -- Clone Numerique

Le StateValidatorService constitue le Clone Numerique de l'application. Il maintient un index complet de tous les fichiers source C# avec leur hash SHA-256 (tronque a 16 caracteres) et leurs metriques de complexite. Cet index sert de reference pour valider que toute modification proposee par l'IA ne degrade pas la qualite du code.

Mecanisme d'indexation

1. Balayage recursif de tous les fichiers .cs (exclusion de obj/ et bin/)
2. Calcul du hash SHA-256 de chaque fichier
3. Comparaison avec le hash mis en cache -- si identique, le fichier est saute
4. Analyse des hotspots via ISourceAnalyzer
5. Stockage du snapshot (CodeFileSnapshot) et du source brut dans un ConcurrentDictionary
6. Suppression des entrees correspondant a des fichiers supprimes

Simulation de patch (SimulatePatch)

Avant toute modification du code, le Clone Numerique simule l'impact du patch en calculant un score composite multi-metriques :

score = 0.35 * normCC
      + 0.15 * normLines
      + 0.20 * normVolume
      + 0.15 * normDifficulty
      + 0.15 * normEffort

Chaque composante norm_X est calculee comme -(delta_X) / (original_X + 1), de sorte qu'une amelioration (reduction) produit un score positif. Le patch n'est accepte que si le score composite depasse le seuil d'amelioration (ImprovementThreshold = 0.05).

6.4 CodePatcher -- Workflow d'approbation

Le CodePatcherService orchestre l'application de patches sur le code source avec un workflow d'approbation configurable.

Flux d'execution

  Patch propose
       |
       v
  +--------------------+
  | SimulatePatch()    |  --- Score <= 0.05 --->  [REJETE : "CloneRejected"]
  | (StateValidator)   |
  +---------+----------+
            |
      Score > 0.05
            |
            v
  +---------+----------+
  | AuditOnly mode ?   |  --- Oui --->  [PROPOSITION EN ATTENTE]
  |                    |                   + GetPendingProposals()
  +---------+----------+                   + ApproveAndApplyAsync()
            |                              + RejectProposalAsync()
          Non
            |
            v
  +---------+----------+
  | Fichier existe ?   |  --- Non --->  [ECHEC : "FileNotFound"]
  +---------+----------+
            |
          Oui
            |
            v
  +---------+----------+
  | Source drift ?     |  --- Oui --->  [ECHEC : "SourceDrift"]
  +---------+----------+
            |
          Non
            |
            v
  +---------+----------+
  | CreateSnapshot()   |  --- Echec --->  [ECHEC : "SnapshotFailed"]
  | (IRollbackService) |
  +---------+----------+
            |
          OK
            |
            v
  +---------+----------+
  | MethodReplacer     |
  | (Roslyn AST)       |  --- Introuvable --->  [ECHEC : "AstNotFound"]
  +---------+----------+
            |
          OK
            |
            v
  +---------+----------+
  | File.WriteAllText  |
  | + Audit Entry      |
  +--------------------+
       |
       v
    [SUCCES]

Mode Audit (defaut entreprise)

Par defaut, le parametre CodePatcherAuditOnly est a true. Dans ce mode, les patches valides par le Clone Numerique ne sont pas appliques automatiquement. Ils sont stockes en tant que propositions dans une liste accessible via GetPendingProposals(). Un operateur humain peut alors :

• Approuver via ApproveAndApplyAsync() -- le patch est re-valide par le Clone puis applique
• Rejeter via RejectProposalAsync() -- la proposition est retiree et l'evenement est audite

L'historique des patches (acceptes, rejetes, echoues) est maintenu dans un buffer circulaire de 100 entrees.

7. Securite et conformite

7.1 Principe Zero Cloud

Le principe Zero Cloud est la contrainte architecturale fondamentale de Coclico. Aucune donnee, aucune metrique, aucun prompt IA n'est jamais transmis a un service exterieur. Cela inclut :

• Inference IA -- Le modele GGUF est charge localement. LLamaSharp effectue l'inference sur le CPU/GPU local.
• Telemetrie -- Toutes les metriques sont stockees dans %AppData%\Coclico\telemetry\.
• Audit -- Les pistes d'audit sont des fichiers NDJSON locaux.
• Parametres -- Stockage exclusif dans settings.json local.
• Snapshots de rollback -- Chiffres via DPAPI et stockes localement.

La seule communication reseau autorisee est la verification de mise a jour (appel HTTPS vers le depot GitHub) et les operations explicitement declenchees par l'utilisateur (Winget, HttpRequest dans les Flow Chains).

7.2 Rollback Safety

Le service RollbackService implemente un mecanisme de points de restauration a double couche :

Couche memoire

• Stockage dans un ConcurrentDictionary<string, (SnapshotMetadata, string)>
• Capacite : 50 snapshots en memoire (FIFO)
• Acces en O(1) pour la restauration

Couche disque

• Repertoire : %AppData%\Coclico\snapshots\
• Chiffrement : DPAPI (ProtectedData.Protect avec DataProtectionScope.CurrentUser)
• Format : Enveloppe JSON contenant les metadonnees et l'etat serialise
• Nettoyage automatique : les snapshots de plus de 30 jours sont supprimes a la fermeture

Chaque snapshot est identifie par un GUID sans tirets (32 caracteres hexadecimaux) et contient les metadonnees suivantes : identifiant, nom du contexte, horodatage UTC, type .NET de l'etat sauvegarde, et taille en octets.

7.3 Politique de securite

Le service SecurityPolicyService implemente une politique de securite a deux niveaux : des regles par defaut non-supprimables et des regles d'entreprise fusionnables chargees depuis %AppData%\Coclico\security-policy.json.

Patterns de commandes bloquees (par defaut)

Patterns PowerShell bloques (par defaut)

Chemins proteges

Les operations de fichiers via les Flow Chains sont bloquees sur les segments de chemin suivants : \windows\, \program files\, \program files (x86)\, \programdata\microsoft\, \system volume information\, \$recycle.bin\, \recovery\, \boot\, \efi\.

L'implementation utilise des FrozenSet<string> pour un matching a haute performance en O(1) amortie. Les wildcards PowerShell sont compiles en Regex avec un timeout de 100ms par pattern pour prevenir les attaques ReDoS.

7.4 Piste d'audit

Le service AuditLogService maintient une piste d'audit append-only au format NDJSON (Newline Delimited JSON). Chaque entree contient :

Les fichiers d'audit sont nommes audit-YYYY-MM-DD.log et stockes dans %AppData%\Coclico\audit\. L'elagage automatique est execute au demarrage selon la duree de retention configuree (defaut : 90 jours). La lecture des entrees recentes s'effectue en parcours inverse (fin vers debut) avec un buffer de 4096 octets emprunte a ArrayPool<byte>.Shared.

8. Telemetrie et observabilite

8.1 DynamicTracerService

Le service DynamicTracerService fournit l'infrastructure de telemetrie de l'application. Il collecte les metriques de performance de toutes les operations instrumentees.

Specifications techniques

API d'instrumentation

Deux modes d'instrumentation sont disponibles :

Mode Span -- Pour mesurer la duree d'un bloc de code :

using var span = tracer.BeginOperation("Feature.Operation", "Category");
// ... code mesure ...
// La duree est enregistree automatiquement au Dispose

Mode Direct -- Pour enregistrer une mesure ponctuelle :

tracer.Record("Feature.Operation", elapsed, "Category", tags);

Agregats statistiques

La methode GetAggregate(string operationName) retourne un objet MetricAggregate contenant :

• Nombre d'echantillons
• Minimum, Maximum, Moyenne
• Percentile 95 (via T-Digest si au moins 5 echantillons, sinon calcul exact)
• Derniere observation

8.2 Algorithmes statistiques

T-Digest (estimation de quantiles en streaming)

L'implementation dans Algorithms/TDigest.cs suit l'algorithme de Dunning et Ertl (2019). Ce structure de donnees permet l'estimation de quantiles (P50, P95, P99) sur un flux de donnees en streaming avec une complexite memoire bornee.

Isolation Forest (detection d'anomalies)

L'implementation dans Algorithms/IsolationForestDetector.cs suit l'algorithme de Liu et al. (2008), adapte pour un usage en streaming incremental.

Lorsqu'une anomalie est detectee, le service identifie les features responsables en calculant le Z-score de chaque dimension et en reportant celles depassant un seuil de 2.0 ecarts-types.

Adaptive Scorer

Le composant AdaptiveScorer integre au OptimizationEngineService calcule un score d'urgence pour le mode fallback deterministe. Les poids sont auto-ajustables : lorsqu'une action s'avere inefficace, le poids CPU augmente et les autres diminuent, avec renormalisation pour maintenir la somme a 1.0.

8.3 Journalisation Serilog

La journalisation est configuree au niveau du conteneur DI avec les parametres suivants :

L'API publique est exposee via la classe statique LoggingService avec les methodes LogInfo, LogError et LogException. La convention impose qu'aucune exception ne soit absorbee silencieusement -- chaque catch doit produire au minimum une entree de journal.

9. Site web

9.1 Architecture Astro

Le site web de Coclico est construit avec le framework Astro, un generateur de sites statiques axe sur la performance. L'architecture technique est la suivante :

Structure du projet

website/
  src/
    components/
      layout/          -- Composants de mise en page
      sections/        -- Sections reutilisables
    i18n/
      index.ts         -- Logique de traduction
      locales/         -- Fichiers de traduction par langue
    layouts/           -- Templates de page
    pages/
      index.astro      -- Page d'accueil (francais, defaut)
      changelog/       -- Notes de version
      docs/            -- Documentation technique
      faq/             -- Questions frequentes
      guide/           -- Guides utilisateur
      wiki/            -- Wiki du projet
      en/              -- Pages anglaises
      de/              -- Pages allemandes
      es/              -- Pages espagnoles
      fr/              -- Pages francaises
    styles/            -- Feuilles de style globales
  public/              -- Ressources statiques (favicon, images)
  astro.config.mjs     -- Configuration Astro
  tailwind.config.mjs  -- Configuration Tailwind

9.2 Internationalisation

Le site supporte quatre langues avec le systeme i18n natif d'Astro :

La configuration impose un trailingSlash: 'always' pour la coherence des URL et le bon fonctionnement du deploiement GitHub Pages.

9.3 Deploiement

Le site est deploye sur GitHub Pages a l'adresse https://coclico-cy.github.io/Coclico/. La configuration de base (base: '/Coclico') assure le bon fonctionnement des liens relatifs dans le contexte d'un sous-repertoire GitHub Pages. Le repertoire de sortie est configure a ../docs pour etre servi directement depuis le depot.

10. Prerequis et deploiement

10.1 Configuration materielle et logicielle

10.2 Installation et premiere execution

1. Installer le runtime .NET 10 Desktop si non present
2. Executer l'installeur Coclico (genere via Coclico_Setup.iss -- InnoSetup)
3. Au premier lancement, accepter l'elevation UAC
4. Configurer le mode de demarrage dans le Launcher (Normal, Minimise, Tray)
5. Optionnel : placer le modele GGUF dans resource/model/IA-support-chat.gguf pour activer l'IA

Stockage des donnees utilisateur

Toutes les donnees sont centralisees dans %AppData%\Coclico\ :

10.3 Commandes de compilation

# Compilation
dotnet build Coclico/Coclico.csproj

# Execution (necessite elevation administrateur)
dotnet run --project Coclico/Coclico.csproj

# Tests unitaires
dotnet test

# Tests filtres par classe
dotnet test --filter "FullyQualifiedName~ServiceCore"

# Restauration des packages
dotnet restore

# Nettoyage complet
dotnet clean

11. Annexe : Structure des repertoires

Coclico/                            -- Racine du depot
  Coclico.slnx                      -- Solution .NET
  Coclico_Setup.iss                  -- Script InnoSetup (installeur)
  LICENSE                            -- Open source (MIT)
  README.md                          -- Documentation en anglais
  README.fr.md                       -- Documentation en francais
  CLAUDE.md                          -- Instructions pour IA assistante

  Coclico/                           -- Projet principal (.NET 10 WPF)
    Coclico.csproj                   -- Fichier projet
    App.xaml / App.xaml.cs           -- Point d'entree, sequence de demarrage
    MainWindow.xaml / .cs            -- Fenetre principale Fluent Design
    AssemblyInfo.cs                  -- Metadonnees d'assemblage
    app.manifest                     -- Manifeste UAC

    Models/
      WorkflowPipeline.cs            -- Modeles Flow Chain (28 NodeTypes)
      LaunchMode.cs                  -- Modes de demarrage

    Views/
      DashboardView.xaml             -- Tableau de bord temps reel
      ProgramsView.xaml              -- Bibliotheque d'applications
      WorkflowPipelinesView.xaml     -- Editeur Flow Chains
      InstallerView.xaml             -- Installeur Rapide (Winget)
      CleaningView.xaml              -- Nettoyage systeme
      ScannerView.xaml               -- Audit d'applications
      RamCleanerView.xaml            -- Nettoyage memoire
      AiChatView.xaml                -- Chat IA local
      SettingsView.xaml              -- Parametres
      HelpView.xaml                  -- Aide
      SplashWindow.xaml              -- Ecran de demarrage
      LauncherWindow.xaml            -- Configuration premier lancement
      ProfileWindow.xaml             -- Profil utilisateur
      AdminPromptWindow.xaml         -- Invite d'elevation UAC
      AvatarCropWindow.xaml          -- Recadrage d'avatar
      RuleSelectionDialog.xaml       -- Selection de regles

    ViewModels/
      DashboardViewModel.cs          -- VM Tableau de Bord
      CleaningViewModel.cs           -- VM Nettoyage
      ScannerViewModel.cs            -- VM Scanner
      SettingsViewModel.cs           -- VM Parametres
      WorkflowPipelinesViewModel.cs  -- VM Flow Chains

    Services/
      ServiceContainer.cs            -- Conteneur DI statique
      AiChatService.cs               -- IA locale dual-executor
      OptimizationEngineService.cs   -- Pipeline autonome 3 etages
      SourceAnalyzerService.cs       -- Analyse Roslyn AST
      StateValidatorService.cs       -- Clone Numerique
      CodePatcherService.cs          -- AutoPatcher avec approbation
      RollbackService.cs             -- Points de restauration DPAPI
      AuditLogService.cs             -- Piste d'audit NDJSON
      SecurityPolicyService.cs       -- Politique de securite
      DynamicTracerService.cs        -- Telemetrie et metriques
      MemoryCleanerService.cs        -- 18 operations P/Invoke
      FeatureExecutionEngine.cs      -- Moteur d'execution avec circuit-breaker
      ResourceAllocatorService.cs    -- QoS processus
      RagService.cs                  -- RAG BM25 + Cosinus TF-IDF
      CleaningService.cs             -- Nettoyage systeme
      InstalledProgramsService.cs    -- Detection multi-sources
      WorkflowService.cs             -- CRUD + execution Flow Chains
      SettingsService.cs             -- Persistance des parametres
      InstallerService.cs            -- Interface Winget
      ThemeService.cs                -- Themes et couleurs
      LocalizationService.cs         -- Internationalisation (10 langues)
      ProfileService.cs              -- Profil utilisateur
      ProcessWatcherService.cs       -- Surveillance des processus
      NetworkMonitorService.cs       -- Surveillance reseau
      StartupService.cs              -- Demarrage automatique Windows
      KeyboardShortcutsService.cs    -- Raccourcis clavier globaux
      LoggingService.cs              -- Abstraction Serilog
      ToastService.cs                -- Notifications toast
      CacheService.cs                -- Abstraction du cache
      ResourceGuardService.cs        -- Gardien de ressources
      SecretScanService.cs           -- Detection de secrets
      SeverityClassifier.cs          -- Classification de severite
      UpdateCheckService.cs          -- Verification de mise a jour
      UpdateManager.cs               -- Gestionnaire de mise a jour
      StartupHealthService.cs        -- Verification de sante au demarrage
      UserAccountService.cs          -- Gestion des comptes
      TrayService.Win32.cs           -- Integration zone de notification

      Algorithms/
        IsolationForestDetector.cs   -- Detection d'anomalies (Liu et al. 2008)
        TDigest.cs                   -- Estimation de quantiles (Dunning 2019)
        MethodReplacer.cs            -- Remplacement AST de methodes
        SimpleStemmer.cs             -- Racinisation pour le RAG

      Interfaces (I*.cs)
        IAiService.cs                -- Contrat service IA
        IAuditLog.cs                 -- Contrat piste d'audit
        ICacheService.cs             -- Contrat cache
        ICodePatcher.cs              -- Contrat auto-patcher
        IDynamicTracer.cs            -- Contrat telemetrie
        IOptimizationEngine.cs       -- Contrat moteur d'optimisation
        IResourceAllocator.cs        -- Contrat QoS
        IRollbackService.cs          -- Contrat rollback
        ISecurityPolicy.cs           -- Contrat politique de securite
        ISourceAnalyzer.cs           -- Contrat analyseur statique
        IStateValidator.cs           -- Contrat clone numerique

    Resources/                       -- Ressources embarquees (icones, traductions)
    Converters/                      -- Convertisseurs XAML
    Properties/                      -- Proprietes d'assemblage
    resource/
      model/                         -- Modele GGUF pour LLamaSharp
      docs/                          -- Documentation pour le RAG

  Coclico.Tests/                     -- Projet de tests (xUnit + Moq)

  website/                           -- Site web (Astro + Tailwind)
    src/
      pages/                         -- Pages multi-langues
      components/                    -- Composants reutilisables
      i18n/                          -- Traductions
      layouts/                       -- Templates
      styles/                        -- CSS global
    public/                          -- Ressources statiques

  docs/                              -- Sortie du build Astro (GitHub Pages)
  Installer/                         -- Artefacts d'installation