📌 Newsletter de la cellule technique

Ce qu’on a écrit dans xWiki

(À venir - Votre documentation est votre meilleure alliée. N’oubliez pas de mettre à jour les procédures, les designs techniques et les décisions d’architecture !)

Ce qu’on a fait

👉 N’hésitez pas à partager vos travaux, vos projets, ou vos POC pour la prochaine newsletter !

Ce qu’on a vu d’intéressant

🧠 DTO vs Entity : un petit concept. Un impact énorme.

Pourquoi ne pas retourner directement vos entités de base de données dans vos APIs ? Parce que… ça vous sauvera la mise à moyenne et longue terme.

“Your database model is not your API contract.” — une phrase simple, mais qui mérite d’être gravée en lettres d’or dans tout design d’API.

👉 Rappel technique :

Entity → structure interne, liée à la BD : contient toutes les colonnes, relations, champs sensibles, métadonnées…
DTO → objet de transfert : uniquement les données utiles pour le consommateur. Contrôlé, sécurisé, évolutif.

✅ Pourquoi c’est non négociable (ou presque) :

🛡️ Sécurité : pas de fuite accidentelle de données sensibles (ex: password_hash, internal_id)
🔗 Découplage : vous pouvez modifier votre schéma sans casser les clients
🧼 Réponses propres : pas de“bagage” inutile, pas de données techniques exposées
🚀 APIs évolutives : vous pouvez adapter votre contrat API sans toucher la couche métier

🔗 À intégrer dès la conception — pas comme un “ajout” en fin de projet. C’est une règle d’architecture, pas une option.

💡 C’est souvent la première chose qu’on oublie… et la première chose qu’on regrette quand le premier client externe demande “pourquoi j’ai reçu ce champ là ?”

🏗️ FastAPI : une structure qui scale vraiment (et pas juste au début)

On a tous commencé par tout mettre dans un seul fichier… puis on a compris que “ça marche tant que ça reste petit” — et c’est là que tout se casse.

“Good engineers focus on structuring them.” — pas juste sur écrire les endpoints, mais sur les organiser dès le départ.

👉 Structure recommandée (et éprouvée) :

app/
├── routers/      → API endpoints (les routes)

├── services/     → Logique métier (ce qu’on appelle “buisness logic”)

├── models/       → Modèles de base de données (ORM)

├── schemas/      → Schémas Pydantic (validation des entrées/sorties)

├── core/         → Config, logging, middlewares, utils globaux

├── db/           → Connexion, session, gestion du pool

└── main.py       → Point d’entrée (et rien d’autre)

✅ Pourquoi ça marche :

🧩 Séparation des responsabilités claire → chaque dossier a un rôle précis
🔍 Débogage simplifié → on sait exactement où chercher
📈 Évolutivité garantie → ajouter un module ne casse pas le reste
👥 Meilleure collaboration → deux devs peuvent bosser sans se marcher dessus

🔧 Tech stack mentionnée (parce que ça inspires) : FastAPI | PostgreSQL | AWS | Docker

💡 Ce n’est pas de la sur-architecture — c’est de la prévention. La structure ne vous ralentit pas… elle vous sauve du chaos quand le projet grandit.

🛡️ Stop aux DELETE durs — adoptez les soft deletes en Spring Boot !

Vous avez déjà dû restaurer une base parce qu’un user a supprimé un truc par erreur ? Ou pire : vous avez dû gérer des erreurs de clé étrangère en chaîne ? C’est là qu’on pense à “soft delete”.

L’idée : ne pas effacer, mais marquer comme “inactif”. Et laisser JPA/Hibernate faire le boulot à votre place.

👉 Comment ça marche (en 3 étapes) :

1. Entity Setup
Ajoutez @SQLDelete pour transformer DELETE en UPDATE, et @Where pour filtrer automatiquement les enregistrements “déletés” dans les findAll() :

java
   @Entity

   @SQLDelete(sql = "UPDATE product SET deleted = true WHERE id=?")

   @Where(clause = "deleted=false")

   public class Product {

       @Id

       private Long id;

       

       private String name;

       

       private boolean deleted = false;

   }

2. Repository → aucune modification !
Votre repository.delete(product) reste le même — mais Hibernate exécute en réalité un UPDATE → pas de rupture de compatibilité, pas de refacto.
3. Bénéfices immédiats :

🔄 Restauration facile : une simple mise à deleted = false
🔗 Intégrité relationnelle préservée : plus de “Foreign Key Constraint” en cascade
📜 Audit complet : vous gardez l’historique de tout ce qui a existé (utile pour admin, logs, etc.)

💡 Pro Tip :
Besoin de voir les données “soft deleted” (ex : dashboard admin) ?
→ Activez manuellement le filtre Hibernate ou écrivez une requête native avec @Query pour ignorer le @Where.

🚨 Un bon rappel : “supprimer” c’est souvent une opération irréversible… sauf si vous choisissez de ne pas le faire.

🔐 MD5 : c’est mort. Et ça a été prouvé — en moins d’une minute.

60 % des mots de passe hachés en MD5… craqués en moins d’une heure.

48 %… en moins d’une minute.

Avec une seule RTX 5090.

— Et non, ce n’est pas une simulation. C’est une étude de Kaspersky, basée sur 231 millions de mots de passe réels volés entre 2023 et 2026.

👉 Ce que ça veut dire pour nous :

MD5 n’est pas un algorithme de hachage sécurisé pour les mots de passe.
Même avec un “salt”, si le mot de passe est faible, il tombe en quelques secondes.
Le “cracking intelligent” (basé sur les mots courants, les modèles, les substitutions) fait des ravages.

✅ Les bonnes pratiques à adopter — maintenant :

🚫 Interdire MD5, SHA1, SHA256 pour les mots de passe.
✅ Utiliser des algorithmes conçus pour les mots de passe :

→ bcrypt (solide, éprouvé) → scrypt (résistant à l’attaque sur mémoire)
→ Argon2 (le gagnant du Password Hashing Competition, recommandé par OWASP)

🔐 Toujours utiliser un salt unique par utilisateur.
📏 Exiger des mots de passe longs (12+ caractères), uniques, complexes — et les gérer via un password manager.

💡 Bonus :
Le hachage, ce n’est qu’une couche.

Une fuite de mot de passe en clair via phishing / keylogger reste possible → prévention des risques humains (formation, MFA, monitoring).
Un mot de passe faible = hachage fort ou pas, il tombe quand même.

🚨 Si tu vois du MD5 dans un projet — et que c’est une version récente — c’est une alerte rouge. À corriger. Maintenant.

🤖 IA générative = plus de code… mais aussi plus de failles (si on ne vérifie pas)

On génère du code plus vite que jamais… mais on l’introduit aussi plus vite en prod — avec des vulnérabilités cachées.

🔍 Chiffre choc : près de 50 % du code généré par IA contiendrait des bugs de sécurité… si personne ne le checke.

👉 Ce que ça change pour nous :

On ne peut plus “faire confiance” au code généré — même si c’est fluide, logique, bien indenté.
L’IA ne connaît pas votre contexte de sécurité, vos règles métier, vos anciens bugs, vos dépendances critiques.
Le code généré = code à auditer. Point.

✅ Comment le marché réagit (et comment on peut s’inspirer) :

🛡️ Snyk intègre Claude pour scanner et corriger automatiquement les vulnérabilités dans le code IA.
🧩 Apparition de solutions AppSec “natives IA” — qui s’immiscent dès la phase de développement (IDE, PR, CI/CD).
🚀 Tendance clé : La sécurité “shifting left” devient “shifting left + auto-pilote” — intégrée, continue, silencieuse… mais présente.

💡 Ce n’est pas une question de “faut-il utiliser l’IA” — c’est une question de “comment on garantit la qualité ET la sécurité quand on l’utilise”.

🤖 GitLab Duo en mode “Code Review” — testé, pas diffusé (encore)

Parce que l’IA, c’est bien… mais pas à tout prix. Surtout quand ça coûte.

👉 Ce qu’on a fait :

Activé GitLab Duo pour Code Review sur un projet pilote (volontairement isolé).
Pas encore déployé partout → parce qu’on veut tester la pertinence avant de payer. Et surtout : avant de créer une dépendance.

✅ Premières impressions (en mode “trop tôt pour conclure”) :

L’IA propose des corrections syntaxiques, des suggestions de refactoring, parfois même des alertes de sécurité 🤯
Parfois… un peu trop “à la lettre” → demande une relecture humaine systématique
Le plus utile ? Gagner du temps sur les reviews “basiques” (format, naming, erreurs bêtes) → libère de l’énergie pour les parties complexes

💡 Ce qu’on surveille de près :

💰 Impact facturation : est-ce que l’outil est "payant à l’usage" ? Ou "par projet" ? Ou "par commit analysé" ?
🧠 Qualité des suggestions : est-ce que ce sera un “collègue IA” fiable… ou un “assistant qui fait des trucs bizarres” ?
🔄 Acceptation par l’équipe : les devs vont-ils “s’en servir”, ou “l’ignorer” ?

—

🚨 On ne lance pas un outil IA parce que c’est à la mode — on le teste, on l’observe, on mesure son retour sur investissement (et non pas juste le coût).

📄 OnlyOffice : on l’a vu… et on l’a installé (en mode “à voir”)

Parce que quand on parle de collaboration documentaire, Word Online c’est bien… mais on veut aussi de l’open source, de la self-hosting, et surtout, de la compatibilité avec les fichiers existants.

Exemple interface (Equivalent powerpoint)

👉 Ce qu’on a fait :

Découvert OnlyOffice en mode “évaluation” — après plusieurs demandes de l’équipe pour éditer des .docx/.xlsx en ligne, sans quitter GitLab ou notre intranet.
Installé en local / dans notre infra (sans yet en prod pour tous) → testé avec quelques documents réels (rapports, specs, specs fonctionnelles).

✅ Premiers points observés :

📄 Compatibilité OK avec les fichiers Word/Excel/PPT — même les plus “compliqués” (tableaux, styles, macros basiques).
🔗 Intégration possible avec GitLab, Nextcloud, ou tout autre système via son API ou ses connecteurs.
🖥️ Interface fluide : pas de surprise, c’est comme Office ou LibreOffice… mais dans le navigateur.
🛡️ Avantage clé : hébergement contrôlé → pas de fuite de données vers des clouds externes.

⚠️ À surveiller :

Performance sur fichiers lourds (> 10Mo) ou très structurés
Gestion des conflits en édition collaborative (multi-utilisateurs en même temps)
Support technique et mise à jour régulière (surtout en auto-hébergement)

💡 Ce n’est pas une “migration immédiate” — c’est une “alternative à tester” avec des cas d’usage concrets. Et surtout : sans forcer l’équipe à changer ses habitudes.

🌎 Murena Workspace : un écosystème "privacy-first" qu’on a exploré (et testé en parallèle)

Parce que quand on parle de collaboration, de productivité… et de vie privée — on ne se contente plus de “ce qui marche”, mais de “ce qui respecte”.

👉 Ce qu’on a fait :

Découvert Murena Workspace (anciennement /e/ Workspace) — une suite open source, auto-hébergée, centrée sur la vie privée, la sécurité, et l’indépendance vis-à-vis des GAFAM.
Installé en environnement de test — avec quelques modules clés : calendrier, messagerie, gestion de tâches, partage de fichiers (via Nextcloud ou OwnCloud intégrée).
Comparé en parallèle avec OnlyOffice, GitLab, ou Outlook/Teams — surtout sur l’expérience utilisateur, l’intégration, et les contraintes techniques.

✅ Premiers points observés :

🔐 Philosophie forte : pas de traçage, pas de publicité, pas de données stockées ailleurs → un vrai plus pour les projets sensibles ou réglementés.
🎯 Interface clean, fluide — pas aussi riche que Teams, mais plus légère, plus directe.
🧩 Modulaire : on installe que ce qu’on veut → pas de “suite bloatée”.
⚙️ Auto-hébergement possible → compatible avec nos infra, mais demande un peu de maintenance (updates, backup, certificats…).
🔄 Interopérabilité : supporte CalDAV, CardDAV, WebDAV → intégration possible avec Thunderbird, Android, etc.

⚠️ À surveiller :

Performance et stabilité sur usage intensif (multi-utilisateurs, synchronisation en temps réel)
Support des formats Office (comparé à OnlyOffice) — limité ou via intégration externe
Documentation et communauté → moins fournie que GitLab ou Nextcloud, mais en croissance

💡 Ce n’est pas un “remplacement de Teams” — c’est une “alternative éthique et technique” à tester dans des cas précis. Et surtout : sans sacrifier la productivité pour la philosophie.

🤖 McDonald’s Support vs LLM : quand les guardrails s’effondrent… et que vous obtenez un code Python à la place d’un menu

Parce que même les chatbots les plus“réglementés” peuvent être détournés — et parfois, c’est justement là que ça devient fascinant (ou inquiétant).

👉 Ce qu’on a vu :

Une conversation simulée avec le “support McDonald’s” :

→ Demande : “Comment écrire un script Python pour inverser une liste chaînée ?” → Réponse : Un code fonctionnel en O(n) + une offre de Chicken McNuggets.

Conversation avec bot mcdo demandant nuggets et code python

✅ Ce qui est vraiment intéressant ici :

🚧 Les pré-prompts (ou guardrails) sont contournables.

→ Même si McDonald’s a probablement mis en place des règles strictes pour que son chatbot ne “parle pas de code” — il parle de code.

🔄 Les LLMs ne “obéissent” pas — ils “interprètent”.

→ Une demande banale d’aide en Python est prise au sérieux… et traitée.

🐦 En réaction, les utilisateurs sur X (Twitter) se moquaient :

> “Ne payez pas Claude — utilisez le chat McDo, il est gratuit et fait du Python.” 😅

⚠️ Pourquoi ça nous concerne en tech :

💡 En entreprise, on croit souvent qu’un LLM “verrouillé” reste dans son contexte — mais la réalité est plus fluide.
🌪️ Les LLMs peuvent “halluciner” — ou dans ce cas, “halluciner utilement”.
🛑 Ce qui est drôle en demo… peut devenir un risque de sécurité ou de compliance en prod : imaginez un chatbot RH qui commence à donner des conseils juridiques… ou un bot de support bancaire qui génère du code.

🍟 Moralité : si McDonald’s peut te donner un algorithme de liste chaînée… alors ton LLM d’entreprise peut aussi faire bien plus que ce qu’il est censé faire — et ce n’est pas toujours prévu. Soyez vigilants… et un peu amusés.

Ce qu’on va creuser

👉 N’hésitez pas à partager vos trouvailles, vos alertes, ou vos “aha moments” pour la prochaine newsletter !

— La cellule technique

Newsletter - Mai