Présentation

Edi Life OS est un tableau de bord personnel qui regroupe habitudes, objectifs, Kanban, finances et suivi de concentration. Le projet, publié sous licence MIT sur GitHub, compte 41 commits, 6 étoiles et un fork. Il s’adresse aux utilisateurs qui souhaitent remplacer plusieurs applications (todo‑list, suivi budgétaire, minuteur Pomodoro, notes) par une interface unique, auto‑hébergée et sans abonnement.

Architecture technique

Le cœur de l’application repose sur PHP 8.1 et MySQL, ce qui la rend compatible avec tout hébergement partagé supportant ces technologies. Le dépôt fournit un Dockerfile et un docker‑compose.yml pour un déploiement containerisé, recommandé pour isoler les dépendances et simplifier la mise à jour. Le Dockerfile officiel se compose de trois étapes :

FROM php:8.1-apache
COPY . /var/www/html/
RUN docker-php-ext-install pdo_mysql

Cette configuration compile l’extension pdo_mysql afin de connecter le serveur PHP à la base de données MySQL. Le fichier .env.example expose les variables d’environnement nécessaires (hôte DB, nom d’utilisateur, mot de passe), ce qui facilite le paramétrage sur des plateformes cloud ou des serveurs VPS.

Intégration de l’IA via le serveur MCP

Une des spécificités d’Edi Life OS est le serveur MCP (Message Control Protocol) intégré. Il expose 26 outils via une API HTTP protégée par token, permettant à des assistants IA tels que Claude de lire le tableau de bord, créer des objectifs SMART, enregistrer des dépenses ou marquer des habitudes comme accomplies. La communication se fait exclusivement au niveau de l’API ; le serveur MCP n’accède jamais directement à la base de données ni aux identifiants, ce qui limite la surface d’attaque. Les requêtes sont typiquement de la forme POST /api/mcp avec un corps JSON décrivant l’action demandée.

Par exemple, un utilisateur peut envoyer :

{
  "action": "create_goal",
  "payload": {
    "title": "Construire un home studio",
    "deadline": "2024-12-31",
    "tasks": ["Acheter panneaux acoustiques"]
  }
}

Le serveur traduit cette instruction en opérations CRUD sur les tables correspondantes, puis renvoie un statut de succès. Cette approche « AI‑ready » repose sur un protocole simple, mais elle exige que le développeur sécurise le token et limite les origines autorisées via CORS.

Limitations et considérations de sécurité

Le projet ne fournit pas de chiffrement natif des données au repos ; la protection dépend du serveur MySQL sous‑jacent. De plus, l’authentification se limite à un système de connexion PHP classique, sans prise en charge d’OAuth ou de SSO, ce qui peut être insuffisant pour des environnements d’entreprise. Le serveur MCP, bien que séparé, expose une surface d’API qui, si le token était compromis, permettrait la modification de toutes les entités du tableau de bord. Il est donc recommandé de placer le service derrière un reverse proxy TLS et d’utiliser des tokens à durée de vie limitée.

Enfin, la localisation du calendrier et de la météo est fixée à Asia/Tehran et Qeshm Island via Open‑Meteo, ce qui peut ne pas convenir à des utilisateurs hors de ces fuseaux horaires. Aucun mécanisme de synchronisation avec des services externes (Google Calendar, Stripe, etc.) n’est fourni, limitant l’interopérabilité.