On écrit les tests avant le code.

Cycle classique :

1. écrire un test qui échoue
2. écrire le code minimum pour le faire passer
3. refactoriser

Cycle appelé Red → Green → Refactor

Avantages :

• code très testable
• moins de bugs
• architecture plus propre

Outils :

• Python : pytest
• C# : xUnit, NUnit
• JS : Jest

2️⃣ Behavior‑Driven Development (BDD)

Extension du TDD orientée comportement utilisateur.

On décrit le comportement avec un langage quasi naturel.

Exemple :

Given user is logged in
When user clicks checkout
Then order is created

Outils :

• Cucumber
• SpecFlow (.NET)
• Behave (Python)

Format Gherkin.

3️⃣ Acceptance Test‑Driven Development (ATDD)

Variante du BDD.

Les tests d’acceptation métier sont écrits avant le développement.

Participants :

• développeurs
• QA
• métier

But : s’assurer que la fonctionnalité correspond au besoin métier.

4️⃣ Domain‑Driven Development (DDD)

Approche architecturale.

On conçoit le logiciel autour du domaine métier.

Concepts :

• Entities
• Value Objects
• Aggregates
• Repositories
• Bounded Context

Très utilisé pour :

• microservices
• architectures complexes

5️⃣ Model‑Driven Development (MDD)

On part de modèles UML ou abstractions, puis on génère le code.

Exemple :

UML → génération code Java / C#

Utilisé dans :

• systèmes industriels
• systèmes embarqués

6️⃣ Specification‑Driven Development (SDD)

Le développement est guidé par une spécification formelle.

Exemple :

• OpenAPI
• contrats d’API
• interface contract

Exemple API :

OpenAPI → génération client + serveur

7️⃣ API‑Driven Development

Très utilisé pour les microservices.

On commence par définir l’API :

OpenAPI / Swagger

Ensuite :

• front
• backend

s’alignent dessus.

8️⃣ Contract‑Driven Development

Basé sur des contrats entre services.

Exemple :

Consumer → définit contrat
Provider → doit respecter contrat

Outils :

• Pact
• Spring Cloud Contract

9️⃣ Security‑Driven Development

La sécurité guide le design.

On part de :

• threat model
• attaques possibles

Puis on code.

Très utilisé pour :

• fintech
• défense
• blockchain

🔟 Data‑Driven Development

Les décisions sont prises à partir des données.

Exemple :

• A/B testing
• analytics
• télémétrie

Autres variantes

On rencontre aussi :

• UI‑Driven Development
• UX‑Driven Development
• Feature‑Driven Development (FDD)
• Performance‑Driven Development
• Event‑Driven Development

Les plus utilisés en pratique

Les 5 plus répandus :

1. TDD
2. BDD
3. DDD
4. API‑Driven Development
5. Contract‑Driven Development

Cet article Les principaux “Driven Development” est apparu en premier sur CYBERDEV s.p.r.l..

Dans cet article, nous allons détailler les recommandations de Google pour sécuriser vos clés d’API et comptes de service, ainsi que les bonnes pratiques à adopter pour éviter les compromissions.

1. Sécuriser le Cycle de Vie des Identifiants

✅ Ne jamais stocker les clés dans le code ou le contrôle de version

• Problème : Les clés d’API et les clés de compte de service ne doivent jamais être commitées dans un dépôt Git (GitHub, GitLab, Bitbucket, etc.).
• Solution :
  • Utiliser Google Secret Manager pour injecter les identifiants uniquement à l’exécution.
  • Configurer des variables d’environnement sécurisées dans votre CI/CD (GitHub Actions, GitLab CI, Cloud Build).

✅ Désactiver les clés dormantes

• Problème : Les clés inutilisées depuis plus de 30 jours représentent un risque inutile.
• Solution :
  • Auditer régulièrement les clés actives via Google Cloud Console ou gcloud CLI.
  • Supprimer les clés inutilisées pour réduire la surface d’attaque.

✅ Restreindre les clés d’API

• Problème : Une clé d’API non restreinte peut être utilisée pour appeler n’importe quelle API Google Cloud, ce qui augmente les risques en cas de fuite.
• Solution :
  • Limiter les API autorisées (ex : uniquement Maps JavaScript API).
  • Appliquer des restrictions d’environnement :
    • Adresses IP (autoriser uniquement certaines plages).
    • Référents HTTP (limiter aux domaines autorisés).
    • Bundle IDs (pour les applications mobiles).

✅ Appliquer le principe du moindre privilège

• Problème : Les comptes de service avec des permissions excessives augmentent les risques en cas de compromission.
• Solution :
  • Utiliser IAM Recommender pour identifier et supprimer les permissions inutilisées.
  • Ne jamais attribuer le rôle Owner ou Editor à un compte de service, sauf si absolument nécessaire.

✅ Imposer une rotation automatique des clés

• Problème : Les clés statiques peuvent être compromises sans que vous le sachiez.
• Solution :
  • Configurer la politique iam.serviceAccountKeyExpiryHours pour imposer une durée de vie maximale (ex : 90 jours).
  • Si possible, désactiver la création de nouvelles clés avec iam.managed.disableServiceAccountKeyCreation.

2. Renforcer les Sauvegardes Opérationnelles

✅ Mettre à jour les contacts essentiels

• Problème : En cas d’incident de sécurité, Google doit pouvoir contacter rapidement les bonnes personnes.
• Solution :
  • Vérifier et mettre à jour les contacts essentiels dans Google Cloud Console (IAM & Admin > Essential Contacts).
  • S’assurer que les alertes critiques (sécurité, facturation) sont envoyées aux bonnes adresses email.

✅ Configurer des alertes de facturation et d’anomalies

• Problème : Une hausse soudaine de consommation peut indiquer une compromission de clé.
• Solution :
  • Activer les alertes de budget dans Google Cloud Billing.
  • Configurer des alertes d’anomalies pour détecter les pics d’utilisation inhabituels.
  • Utiliser Cloud Monitoring pour surveiller les activités suspectes.

3. Outils et Commandes Utiles

🔧 Auditer les clés de compte de service

# Lister les clés de compte de service
gcloud iam service-accounts keys list --iam-account=SA_EMAIL@PROJECT_ID.iam.gserviceaccount.com

# Supprimer une clé
gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_EMAIL@PROJECT_ID.iam.gserviceaccount.com

🔧 Vérifier les restrictions d’une clé d’API

# Lister les clés d'API
gcloud alpha services api-keys list

# Voir les restrictions d'une clé
gcloud alpha services api-keys get-key-string API_KEY

🔧 Configurer une politique de rotation des clés

# Définir une durée de vie maximale (ex : 90 jours)
gcloud resource-manager org-policies enable-enforce \
    iam.serviceAccountKeyExpiryHours --organization=ORG_ID --duration=2160h

Conclusion : Adopter une Approche Zero Trust

Google insiste sur l’importance d’une stratégie de sécurité unifiée pour protéger vos identifiants cloud. En suivant ces bonnes pratiques, vous réduisez considérablement les risques de fuites de clés, d’accès non autorisés et de compromissions.

🔹 Checklist de Sécurité

Cet article Sécurité des Clés d’API et des Comptes de Service Google Cloud : Bonnes Pratiques est apparu en premier sur CYBERDEV s.p.r.l..

• Tu branches ton téléphone ou tablette Samsung à un écran externe (HDMI/USB‑C ou via dock/Hub).
  Tu peux connecter clavier + souris.
• L’interface passe en mode “bureau” : fenêtres, barre des tâches, raccourcis, etc.
  Mais ce n’est PAS Windows :
  
  • Ça reste Android, avec une surcouche “desktop”.
  • Ce sont les applications Android qui tournent, pas des applis Windows classiques (.exe).

On peut voir ça comme :

“Android + interface façon PC”, pas “un téléphone qui devient un vrai PC Windows”.

2️⃣ Pourquoi cette techno n’a pas pris plus d’ampleur ?

Il y a plusieurs raisons, techniques mais surtout… économiques et d’usage.

a) Les applis ne sont pas pensées pour un vrai “bureau”

Même si l’interface DeX ressemble à un PC :

La plupart des applis Android sont pensées pour :

• écran tactile, format vertical,
  usage “mobile”, pas multi-fenêtres intensif.
  Sur DeX :
  
• Certaines applis gèrent mal la fenêtrisation, beaucoup ne sont pas optimisées pour clavier/souris,
  Certaines refusent de s’ouvrir (apps de streaming, banque, etc.).

Résultat : pour un usage pro/productivité sérieux, tu te heurtes vite à des limites.
Un “vrai” PC reste meilleur en bureautique avancée, dev, graphisme, etc.

b) Cas d’usage trop “niche” pour le grand public

DeX est surtout intéressant pour :

• des pros en déplacement,
• des travailleurs en “hot desk” (un écran sur chaque bureau, tu poses ton tel et tu bosses),
• des gens qui veulent remplacer un PC basique (web, mail, bureautique simple).

Mais le grand public :

a déjà souvent un ordinateur portable à la maison,
ou ne ressent tout simplement pas le besoin de brancher le téléphone à un écran.

Ça crée un décalage :

• Techniquement, c’est cool.
  
• Commercialement, ce n’est pas un besoin massif → donc peu de mise en avant, peu d’investissement.

c) Le coût et les accessoires : pas si “magique” que ça

Sur le papier : “Un seul appareil pour tout faire, ton téléphone devient ton PC”.

En pratique :

Il faut :

• un téléphone haut de gamme (Samsung S / Note / certains A récents),
  
• un ou plusieurs écrans compatibles,
  
• souvent un dock ou un hub USB‑C, un clavier, une souris.
  
• Un PC portable d’entrée/milieu de gamme ne coûte pas beaucoup plus cher qu’un smartphone haut de gamme seul.

Du point de vue d’un utilisateur moyen :

Acheter un PC + un téléphone moyen est souvent plus logique qu’acheter un téléphone très cher + tout un setup écran/dock.

d) Limites techniques (surtout au début)

Aujourd’hui, les SoC mobiles sont très puissants, mais longtemps :

Performances OK pour la bureautique, mais :

• limitées pour le multitâche lourd, throttling (chauffe → baisse de fréquence),stockage et RAM plus limités qu’un PC.
  Et surtout :
• Samsung ne peut pas faire tourner des apps Windows nativement sur Android/ARM.
  DeX n’est qu’un mode d’affichage, pas un changement de système.

Pour transformer un téléphone en “vrai PC”, il faudrait :

soit de la virtualisation (Windows en VM, bureau à distance…),
soit que les gens se contentent d’applis 100 % web/cloud (ce que certains font déjà).

e) Intérêt économique limité pour les gros acteurs

Un point important que les gens oublient souvent :

Les constructeurs (Samsung, Apple, etc.) gagnent de l’argent en te vendant :

• un téléphone
  
• un PC / Mac / tablette
  
• des accessoires.
  Si ton téléphone remplace ton PC, ça peut réduire les ventes de laptops.

Donc :

Samsung garde DeX comme fonction “plus” pour se différencier, surtout côté pro,
mais ce n’est pas leur cheval de bataille n°1 auprès du grand public.

Et côté Google/Android :

Il existe un “desktop mode” expérimental dans Android, mais Google ne le pousse quasiment pas.
Ils poussent beaucoup plus ChromeOS (Chromebooks) pour le rôle de “PC léger”.

3️⃣ Vraiment aucune concurrence ? En fait, si, mais discrète

En réalité, Samsung n’est pas totalement seul sur ce terrain, mais :

Les concurrents sont moins connus, certains sont réservés à certains marchés (Chine, etc.), d’autres ont été abandonnés.

Quelques exemples :

✅ Ce qui existe / a existé :

• Huawei Easy Projection / EMUI Desktop
  
• Fonction très proche de DeX : tu branches ton Huawei à un écran, tu as un bureau façon PC.
  Problème : l’embargo US a fortement freiné Huawei hors de Chine.

Motorola Ready For
Sur certains Moto (Edge, etc.) : bureau Android sur écran externe, très similaire à DeX.

Mode bureau d’Android (expérimental)
Inclut dans Android depuis Android 10, mais :

   non activé par défaut,
   peu poli, peu mis en avant par Google.

Anciennes tentatives “téléphone = PC” :

   Motorola Atrix (2011) avec son Lapdock,
   Ubuntu Touch / Ubuntu Convergence (Ubuntu Phone),
   Windows 10 Mobile Continuum (Microsoft : ton téléphone Lumia devenait une sorte de PC Windows simplifié).

Toutes ces tentatives se sont cassé les dents soit par manque d’applis, soit par échec de la plateforme complète (Windows Mobile, Ubuntu Phone…).

🔄 Alternatives “proches mais pas identiques”

Ce n’est pas la même approche, mais ça répond à un besoin similaire “un appareil léger pour faire du PC” :

• Chromebooks (ChromeOS + apps Android) : Laptops très légers, pas basés sur ton téléphone, mais très liés au cloud Google.
  
• iPad + clavier + souris + Stage Manager : Apple pousse l’iPad comme “remplacement potentiel du PC” mais ne propose pas un vrai mode bureau à partir de l’iPhone.
• Bureau à distance / Cloud PC : Tu utilises ton téléphone ou ta tablette comme “terminal” pour te connecter à un vrai PC dans le cloud (Remote Desktop, Shadow, etc.).

4️⃣ En résumé

Samsung DeX est une super démo technologique, très pratique dans certains contextes (pros, nomades, voyages, postes partagés).
Mais ça n’a pas explosé car :

• les applis Android ne sont pas conçues comme des applis PC,
  
• le besoin grand public est limité,
  
• PC portables bon marché restent plus simples à comprendre pour tout le monde,les gros acteurs n’ont pas d’intérêt économique énorme à pousser fort ce concept.
  
• Il existe de la concurrence, mais très peu visible (Huawei, Motorola, modes bureau cachés d’Android, anciennes tentatives de Microsoft/Ubuntu).

Cet article Samsung DeX est apparu en premier sur CYBERDEV s.p.r.l..

Mais qu’est-ce que c’est exactement, et surtout, existe-t-il des alternatives gratuites pour nous, développeurs ?

C’est quoi JPEGmini ?

JPEGmini est une technologie de compression d’image brevetée qui permet de réduire la taille des fichiers JPEG (souvent jusqu’à 80 %) sans affecter la qualité perceptuelle.

Contrairement aux compresseurs classiques qui appliquent une compression mathématique uniforme, JPEGmini utilise un algorithme qui imite le système visuel humain. Il analyse l’image zone par zone pour déterminer combien de “détails” peuvent être supprimés avant que l’œil humain ne remarque une différence.

Le résultat ? Une image qui pèse beaucoup moins lourd, mais qui semble identique à l’originale à l’œil nu.

Alternatives Open-Source et Gratuites

Bien que JPEGmini soit très performant, c’est un logiciel propriétaire et payant. Si vous cherchez des solutions similaires pour vos serveurs ou vos pipelines de développement sans passer à la caisse, voici les meilleures alternatives :

MozJPEG (par Mozilla) : Probablement le meilleur compromis actuel. C’est un encodeur JPEG amélioré qui produit des fichiers plus petits que la libjpeg standard, tout en restant compatible avec tous les navigateurs.
Guetzli (par Google) : Un encodeur perceptuel qui vise une qualité visuelle irréprochable. Attention cependant, il est très lent à l’encodage (gourmand en CPU), à réserver pour du traitement hors ligne.
ImageMagick : Le “couteau suisse” de la manipulation d’images. Avec une commande simple (convert -quality 85 input.jpg output.jpg), on obtient des résultats décents, bien que moins optimisés que MozJPEG.
TinyPNG / TinyJPG : Un service en ligne très populaire (avec une API gratuite limitée) qui compresse intelligemment les PNG et JPEG.

Comment l’intégrer dans vos scripts Python ?

En tant que développeur, vous n’avez pas toujours envie d’installer des binaires complexes. Voici comment automatiser la compression d’images directement dans vos scripts Python.

1. La méthode native avec Pillow (PIL)

C’est la méthode la plus simple. La librairie Pillow permet de sauvegarder une image en activant l’option d’optimisation des tables de Huffman.

from PIL import Image

def compresserimage(inputpath, outputpath):
    try:
        img = Image.open(inputpath)
         'optimize=True' force l'encodeur à faire une passe supplémentaire
         'quality=85' est le "sweet spot" entre poids et qualité visuelle
        img.save(outputpath, "JPEG", quality=85, optimize=True)
        print(f"Image sauvegardée : {outputpath}")
    except Exception as e:
        print(f"Erreur : {e}")

compresserimage("monimage.jpg", "monimageopt.jpg")

2. Utiliser MozJPEG via subprocess

Si vous avez besoin d’une compression plus agressive type “production”, le mieux est d’installer l’exécutable mozjpeg (ou cjpeg) sur votre machine et de l’appeler via Python.

import subprocess

subprocess.run(["cjpeg", "-quality", "85", "-outfile", "output.jpg", "input.jpg"])

3. Via une API (JPEGmini ou TinyPNG)

Si vous avez un compte (clé API), vous pouvez envoyer l’image à traiter sur leurs serveurs via la librairie requests. C’est utile si vous ne voulez pas gérer la charge CPU de la compression sur votre propre serveur.

1. Le concept clé : La “Quantification Adaptative”

Le format JPEG divise l’image en blocs de 8×8 pixels. Pour chaque bloc, il applique une transformation (DCT – Discrete Cosine Transform) puis supprime des détails (Quantification).

JPEG standard : Applique la même force de compression sur toute l'image.
Ton logiciel (type JPEGmini) : Doit analyser chaque zone de l'image.
    Zone de ciel bleu (faible fréquence) : L'œil voit très bien les défauts -> Faible compression.
    Zone de forêt dense (haute fréquence) : L'œil est distrait par le chaos -> Forte compression (masquage visuel).

2. Les briques techniques à assembler

Si tu veux le coder, tu ne vas pas réécrire l’encodeur JPEG bit par bit (trop complexe et lent en Python/C pur). Tu vas plutôt écrire un optimiseur qui pilote un encodeur existant.

Voici les étapes logiques : A. Le changement d’espace colorimétrique (Luminance vs Chrominance)

L’œil humain est très sensible à la luminosité (Luma), mais peu à la couleur (Chroma).

Action : Convertir RGB en YCbCr.
Technique : Appliquer un sous-échantillonnage (Chroma Subsampling) en 4:2:0. Cela divise déjà le poids des couleurs par 2 sans perte visible.

B. La métrique de qualité “Humaine” (Le juge)

C’est le cœur du système. Tu ne peux pas utiliser le MSE (Mean Squared Error). Tu as besoin d’une métrique qui “voit” comme un humain.

SSIM (Structural Similarity Index) : Compare la structure (contours) plutôt que les pixels bruts.
Butteraugli (par Google) : C'est la métrique utilisée par l'encodeur Guetzli. Elle simule précisément la psychophysique de la vision humaine.
DSSIM : Une variation du SSIM orientée vers la perception de la distance visuelle.

C. La boucle d’optimisation (L’algorithme)

Ton code doit trouver le seuil de compression maximal (Q) avant que la métrique (SSIM ou Butteraugli) ne chute en dessous d’un seuil acceptable.

Algorithme simplifié :

Prendre une image source.
Encoder l'image avec une qualité JPEG de 95 (très haute).
Calculer le score SSIM entre la source et la version compressée.
Si le score est > 0.98 (indiscernable), baisser la qualité à 90.
Répéter (recherche dichotomique) jusqu'à trouver la qualité la plus basse où le SSIM reste acceptable.

Conclusion

JPEGmini reste un outil incroyable pour sa simplicité “drag-and-drop”, mais pour un développeur, combiner Python et MozJPEG (ou simplement Pillow bien configuré) permet souvent d’atteindre des résultats très proches gratuitement.

Cet article JPEGmini : Le secret pour réduire vos images est apparu en premier sur CYBERDEV s.p.r.l..

C’est un diagramme de séquence représentant le flux d’une requête dans une infrastructure web sécurisée, avec monitoring et logging. Voici les étapes clés :

1. Couche Sécurité (Firewall) :
   • Vérifications : Filtrage géographique (geo-fencing), restriction par IP, limitation du nombre d’appels (rate limiting), et logging des tentatives.
   • Action : Si la requête est autorisée, elle est transmise au Load Balancer.
2. Load Balancer :
   • Health Checks : Vérifie régulièrement la disponibilité des serveurs IIS (via des requêtes de type healthchecks/monitor).
   • Sécurité : Ajoute son propre logging (ex : journalisation des requêtes entrantes/sortantes).
   • Routing : Achemine la requête vers un serveur IIS disponible.
3. Serveur IIS (Application Web) :
   • Traitement : Reçoit la requête, génère des logs envoyés à Graylog (centralisation des logs).
   • Base de données : Stocke un nouveau message (ex : données métier comme un ticket de transport).
   • Metrics : Grafana interroge IIS (via Prometheus, un outil de collecte de métriques) pour récupérer des statistiques (ex : temps de réponse, erreurs, trafic). Note : Le schéma suggère que IIS expose des métriques au format compatible avec Prometheus (ex : endpoint /metrics).
4. Outils de Monitoring :
   • Graylog : Agrège les logs pour analyse (ex : détection d’anomalies).
   • Grafana + Prometheus : Visualise les performances en temps réel (dashboard).

Cet article Schéma basique d’une API au niveau de l’infrastructure est apparu en premier sur CYBERDEV s.p.r.l..

Vue d’ensemble

Ce diagramme décrit un pipeline CI/CD automatisé depuis la récupération du code jusqu’au déploiement sur un backend server, avec génération de documentation, analyse de qualité, gestion des secrets et publication d’artefacts.

Objectifs:

• Standardiser la compilation et le déploiement.
• Garantir la qualité (SonarQube) et la traçabilité (Nexus, dokuwiki).
• Sécuriser les secrets et prérequis avant déploiement.

KPIs/SLAs (suggestion):

• Durée pipeline: ≤ 15 min sur branche main.
• Taux d’échec étape “quality gate”: < 5%.
• Taux de déploiement test réussi: > 98%.
• MTTR incident de déploiement: < 30 min.

Légende et conventions

• Acteurs:
• Jenkins: orchestrateur de pipeline.
• Jenkins agent: exécuteur (PowerShell) sur nœud build/deploy.
• Gitea: SCM hébergeant le code source.
• SonarQube: analyse qualité + quality gate.
• dokuwiki: publication documentation générée.
• Nexus: registry d’artefacts (binaire/versionné).
• Secret server: coffre-fort (secrets/credentials/certificats).
• Database server: cible des migrations.
• backend server: cible du déploiement applicatif.
• Flux:
• → demande/commande.
• →→ interaction réseau HTTP(S)/API, SSH, ou protocole dédié.
• Étapes “Jenkins agent -> Jenkins agent”: traitements locaux (scripts).

Description détaillée du flux

1) Orchestration/checkout

• Jenkins déclenche l’agent avec un job qui orchestre compilation et déploiement (PowerShell).
• L’agent récupère le code depuis Gitea (checkout, branch/tag selon paramètre).
• Gitea renvoie l’état du repo (réponse à la requête clone/fetch).

2) Documentation automatique

• L’agent génère la doc (ex: DocFX, MkDocs, Doxygen) à partir des sources.
• Publication vers dokuwiki (API/CLI) pour centraliser la doc de version.

3) Qualité du code

• L’agent envoie le code à SonarQube (scanner).
• SonarQube retourne un score/quality gate (Pass/Fail). Le pipeline s’arrête en cas d’échec.

4) Build et artefact

• Compilation locale (PowerShell/MSBuild/Gradle/etc.).
• Push de l’artefact versionné vers Nexus (groupId/artifactId/version).

5) Déploiement en environnement de test

• Jenkins ordonne à l’agent de déployer.
• L’agent tire l’artefact exact depuis Nexus (checksum).
• Contrôles préalables sur backend server: certificats installés/valides, espace disque, ports ouverts, services requis.
• Récupération des secrets depuis Secret server (en lecture, jeton court).
• Mise à jour des fichiers de configuration avec secrets/variables d’environnement.
• Migrations sur Database server (idempotentes, versionnées).
• Déploiement de l’artefact sur backend server (service stop/update/start + healthcheck).

Pré-requis techniques

• Jenkins:
• Agent avec droits limités, labels appropriés (windows/linux selon build).
• Credentials Binding pour Gitea/Nexus/SonarQube/Secret server.
• SCM (Gitea):
• Branch protection pour main.
• Webhooks optionnels si déclenchement auto.
• SonarQube:
• Quality gate défini (coverage, bugs, code smells, vulnérabilités).
• Nexus:
• Repository format conforme (maven/npm/nuget/docker). Rétention et snapshot policy.
• Secret server:
• Accès par rôle (RBAC), secrets rotatifs, audit.
• Backend/DB:
• Comptes de déploiement et de migration distincts.
• Politique de backup avant migration (RPO/RTO fixés).

Sécurité et conformité (RGPD/IT Sec)

• Secrets:
• Jamais en clair dans logs/artefacts; masquage activé dans Jenkins.
• Jetons courts TTL; rotation automatique; principe du moindre privilège.
• Chaîne d’intégrité:
• Checksum/SHA256 de l’artefact Nexus avant déploiement.
• Signature d’artefacts recommandée (GPG).
• Trafic:
• TLS obligatoire vers Gitea, SonarQube, Nexus, dokuwiki et Secret server (mTLS conseillé).
• Traçabilité:
• Lier buildId ↔ commit ↔ artefact ↔ déploiement (annotations Nexus, release notes dokuwiki).
• Données personnelles:
• Si le code traite des données RGPD, s’assurer que les environnements de test sont anonymisés.

Runbook opératoire (résumé)

• Déclenchement:
• Manuel via Jenkins avec paramètres (branche, version, env) ou webhook sur push/tag.
• Garde-fous:
• Stop pipeline si quality gate Fail.
• Stop si vérifs prérequis KO (disque/certificats/ports).
• Stop si migrations échouent (rollback).
• Validation:
• Healthcheck applicatif (HTTP 200/ready), tests fumée post-deploy.
• Publication:
• Doc versionnée sur dokuwiki; artefact publié Nexus; ticket change mis à jour.

Gestion des incidents (checklist)

• Échec checkout Gitea:
• Vérifier credentials, ACL repo, disponibilité Gitea.
• Échec SonarQube:
• Consulter quality gate; corriger règles bloquantes; relancer job.
• Échec push/pull Nexus:
• Vérifier repo cible, quota, URL/credentials; retenter avec checksum.
• Prérequis backend KO:
• Certificats expirés? Espace disque? Ports/pare-feu? Rétablir puis relancer étape.
• Secrets indisponibles:
• Jeton expiré/ACL; régénérer; vérifier rotation automatique.
• Migration DB échouée:
• Identifier migration N; restaurer backup; corriger script idempotent; rejouer.
• Déploiement KO:
• Logs service, revert à version précédente depuis Nexus (promote/rollback).

MTTR cible: < 30 min; escalade au-delà.

Monitoring et métriques

• Jenkins: durée par stage, taux de réussite, queue time.
• SonarQube: debt ratio, coverage, vulnérabilités critiques.
• Nexus: téléchargements par artefact/version, space usage.
• Backend: CPU/RAM, temps de réponse, taux d’erreur, logs applicatifs.
• DB: temps de migration, verrous, temps requêtes clés.

RACI synthétique

• Dév: qualité code, tests, versionning, doc auto.
• IT CI/CD: Jenkins, agents, credentials, gabarits pipeline, intégrations.
• SecOps: politiques secrets, certificats, scans vulnérabilités.
• DBA: scripts de migration, sauvegardes, restauration.
• Ops/Prod: systèmes backend, supervision, déploiements et rollback.

Améliorations recommandées

• Signature et attestation d’artefacts (SLSA niveau 2+).
• Environnements éphémères par PR pour tests.
• Blue/Green ou Canary sur backend server pour zéro-downtime.
• Tests smoke automatisés après déploiement et gate sur healthcheck.
• Promotion d’artefacts (test → preprod → prod) via le même binaire.

Glossaire

• Artefact: binaire ou bundle déployable produit par le build.
• Quality gate: seuils bloquants de qualité SonarQube.
• Idempotent: exécution répétée sans effets indésirables supplémentaires.

Il faut encore ajouter les gestions des certificats, le loadbalancer, le dns et la conteneurisation.

Cet article Schéma basique d’un plan CI/CD est apparu en premier sur CYBERDEV s.p.r.l..

Les WebSockets sont une technologie qui permet une communication bidirectionnelle en temps réel entre un client (généralement un navigateur web) et un serveur. Cette technologie a révolutionné la façon dont les applications web fonctionnent, permettant des interactions plus fluides et plus interactives.

Un peu d’histoire

Les WebSockets ont été introduits pour la première fois en 2008 par Ian Hickson, un développeur web connu pour son travail sur les standards web. La spécification WebSocket a été publiée en 2011 et a rapidement été adoptée par les principaux navigateurs web.

Comment ça marche ?

Les WebSockets fonctionnent en établissant une connexion persistante entre le client et le serveur. Une fois la connexion établie, les deux parties peuvent envoyer des messages à l’autre en temps réel. Les WebSockets utilisent le protocole TCP/IP pour établir la connexion et permettent une communication full-duplex, c’est-à-dire que les deux parties peuvent envoyer et recevoir des messages simultanément.

Exemple de code

Voici un exemple de code Python qui utilise la bibliothèque websockets pour créer un serveur WebSocket simple :

import asyncio
import websockets

async def handle_connection(websocket):
    while True:
        try:
            message = await websocket.recv()
            print(f"Reçu : {message}")
            await websocket.send(f"Écho : {message}")
        except websockets.ConnectionClosed:
            print("Connexion fermée")
            break

async def main():
    async with websockets.serve(handle_connection, "localhost", 8765):
        print("Serveur démarré sur le port 8765")
        await asyncio.Future()  # Exécuter indéfiniment

asyncio.run(main())

Ce code crée un serveur WebSocket qui écoute sur le port 8765 et répond aux messages en écho.

Exemple d’utilisation

Les WebSockets sont utilisés dans de nombreuses applications, notamment :

• Les applications de chat en temps réel
• Les jeux en ligne multijoueurs
• Les applications de collaboration en temps réel (par exemple, les éditeurs de documents en ligne)
• Les systèmes de notification en temps réel

Dans l’exemple que j’ai donné plus haut, les WebSockets sont utilisés pour créer une application de contrôle à distance. Lorsqu’un message est reçu par le serveur, il peut déclencher une action spécifique, comme ouvrir une page web ou lancer une application.

En résumé, les WebSockets sont une technologie puissante qui permet une communication en temps réel entre les clients et les serveurs. Ils sont utilisés dans de nombreuses applications et offrent une grande flexibilité et une grande interactivité. Si vous souhaitez en savoir plus sur les WebSockets, je vous encourage à explorer les ressources disponibles en ligne et à expérimenter avec cette technologie.

Cet article Les WebSockets : Une Technologie de Communication en Temps Réel est apparu en premier sur CYBERDEV s.p.r.l..

Qu’est-ce que Double Driver ?

Double Driver est un logiciel gratuit et open-source qui permet de sauvegarder et de restaurer vos pilotes de périphériques. Il est conçu pour fonctionner sous Windows et est compatible avec les versions 32 et 64 bits.

Pourquoi sauvegarder vos pilotes ?

Lorsque vous réinstallez votre OS, vous risquez de perdre les pilotes de vos périphériques, ce qui peut entraîner des problèmes de fonctionnement. En sauvegardant vos pilotes avant la réinstallation, vous pouvez les restaurer rapidement et facilement après l’installation, ce qui vous permettra de retrouver vos périphériques fonctionnels.

Les avantages de sauvegarder vos pilotes avec Double Driver

Double Driver offre plusieurs avantages :

• Sauvegarde facile et rapide : Double Driver permet de sauvegarder vos pilotes en quelques clics. Il analyse votre système et identifie les pilotes installés, puis les sauvegarde dans un emplacement de votre choix.
• Restauration simplifiée : Après avoir réinstallé votre OS, vous pouvez restaurer vos pilotes sauvegardés à l’aide de Double Driver. Le logiciel réinstalle les pilotes et vous permet de retrouver vos périphériques fonctionnels.
• Génération de listes de pilotes : Double Driver peut générer une liste de vos pilotes installés, ce qui vous permet de vérifier les versions et les fabricants des pilotes.
• Compatibilité avec différentes versions de Windows : Double Driver est compatible avec les versions récentes de Windows, ce qui en fait un outil polyvalent pour les utilisateurs de différentes versions du système d’exploitation.

Comment utiliser Double Driver ?

L’utilisation de Double Driver est simple :

1. Téléchargez et installez Double Driver sur votre système.
2. Lancez le logiciel et cliquez sur “Sauvegarder” pour sauvegarder vos pilotes.
3. Choisissez l’emplacement où vous souhaitez sauvegarder vos pilotes.
4. En cas de réinstallation de votre OS, lancez Double Driver et cliquez sur “Restaurer” pour restaurer vos pilotes sauvegardés.

En résumé, sauvegarder vos pilotes avec Double Driver est une précaution essentielle avant une réinstallation d’OS. Ce logiciel gratuit et facile à utiliser vous permet de sauvegarder et de restaurer vos pilotes de périphériques, ce qui vous évite les problèmes potentiels liés à la perte de vos pilotes. En prenant quelques minutes pour sauvegarder vos pilotes, vous pouvez vous assurer que vos périphériques fonctionneront correctement après la réinstallation de votre OS.

Cet article Sauvegarder vos pilotes avec Double Driver : une précaution indispensable avant une réinstallation d’OS est apparu en premier sur CYBERDEV s.p.r.l..

Dans le monde du développement logiciel, le terme craftsmanship (ou artisanat du code) est souvent associé à une philosophie qui va bien au-delà de la simple écriture de lignes de code. Il s’agit d’une approche qui met l’accent sur l’excellence, la qualité et la passion dans le travail du développeur. Inspiré par les métiers artisanaux traditionnels, le craftsmanship prône une attention méticuleuse aux détails, une amélioration continue et une fierté dans le travail bien fait. Dans cet article, nous allons explorer ce qu’est le craftsmanship et vous donner quelques exemples concrets pour illustrer cette philosophie.

Qu’est-ce que le craftsmanship ?

Le craftsmanship, dans le contexte du développement logiciel, repose sur plusieurs principes fondamentaux :

1. La qualité avant tout : Un artisan du code ne se contente pas de faire fonctionner un programme. Il s’assure que le code est propre, maintenable et performant.
2. L’amélioration continue : Les artisans cherchent constamment à améliorer leurs compétences, à apprendre de nouvelles technologies et à affiner leur maîtrise des outils existants.
3. La collaboration : Le craftsmanship valorise le travail en équipe, les retours constructifs et le partage des connaissances.
4. La fierté du travail bien fait : Un artisan prend du plaisir à coder et ressent une satisfaction profonde lorsqu’il livre un produit de qualité.

Quelques exemples de craftsmanship en action

1. Le refactoring constant
   Imaginons un développeur travaillant sur une application web. Il remarque qu’une fonctionnalité, bien que fonctionnelle, est difficile à maintenir en raison d’un code mal structuré. Plutôt que de laisser ce problème pour plus tard, il prend le temps de refactoriser le code, en le rendant plus lisible et modulaire. Par exemple, il pourrait transformer un bloc de code spaghetti comme ceci :

   if (condition) { doSomething(); } else { doSomethingElse(); }

en une structure plus claire :

   function handleCondition(condition) {
       return condition ? doSomething() : doSomethingElse();
   }

Ce type de travail, bien que parfois invisible pour l’utilisateur final, est au cœur du craftsmanship.

2. L’écriture de tests unitaires
   Un autre exemple concret est l’adoption rigoureuse des tests unitaires. Un artisan du code ne se contente pas de vérifier que son programme fonctionne manuellement. Il écrit des tests automatisés pour chaque composant, garantissant ainsi que le code reste stable même après des modifications futures. Par exemple, pour une fonction simple comme une calculatrice, un test unitaire pourrait ressembler à ceci :

   def test_addition():
       assert add(2, 3) == 5

Cette pratique reflète l’engagement envers la qualité et la prévention des bugs.

3. La documentation claire et concise
   Un artisan ne néglige pas non plus la documentation. Lorsqu’il écrit une fonction complexe, il s’assure d’inclure des commentaires clairs et des docstrings informatives. Par exemple, pour une fonction Python :

   def calculate_discount(price, discount_rate):
       """
       Calcule le prix après application d'une remise.

       :param price: Le prix initial (float)
       :param discount_rate: Le taux de remise (float entre 0 et 1)
       :return: Le prix après remise (float)
       """
       return price * (1 - discount_rate)

Cette attention aux détails facilite la compréhension et la maintenance du code par d’autres développeurs.

4. L’utilisation des principes SOLID
   Les artisans du code adhèrent souvent aux principes SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) pour concevoir des systèmes modulaires et extensibles. Par exemple, au lieu d’écrire une classe monolithique, un artisan pourrait diviser la logique en plusieurs classes respectant le principe de responsabilité unique (Single Responsibility Principle).

Pourquoi adopter le craftsmanship ?

Adopter le craftsmanship, c’est s’engager dans une démarche qui valorise non seulement le produit final, mais aussi le processus de création. Cela peut sembler exigeant, mais les bénéfices sont nombreux :

• Des logiciels plus robustes et moins sujets aux bugs.
• Une meilleure collaboration au sein des équipes.
• Une satisfaction personnelle accrue pour les développeurs.
• Une réduction des coûts à long terme grâce à une meilleure maintenabilité.

Conclusion

Le craftsmanship n’est pas une simple tendance, mais une philosophie qui peut transformer la manière dont nous abordons le développement logiciel. En mettant l’accent sur la qualité, l’amélioration continue et la fierté du travail bien fait, les artisans du code contribuent à créer des logiciels qui non seulement fonctionnent, mais qui sont également durables et agréables à utiliser. Alors, pourquoi ne pas essayer d’intégrer quelques pratiques de craftsmanship dans vos projets ? Vous pourriez être surpris par les résultats !

N’hésitez pas à partager vos propres expériences ou exemples de craftsmanship dans les commentaires !

Cet article Le Craftsmanship : L’art de coder avec passion et excellence est apparu en premier sur CYBERDEV s.p.r.l..

Chargement de l’assemblage OracleClient

Le script débute par tenter de charger l’assemblage nécessaire pour interagir avec Oracle, System.Data.OracleClient, en utilisant la méthode LoadWithPartialName. Cette méthode est obsolète et il est recommandé d’utiliser Add-Type avec le chemin complet de l’assembly pour les versions actuelles de PowerShell. Si l’assemblage est chargé avec succès, un message de confirmation s’affiche. Dans le cas contraire, un message d’erreur est affiché et le script se termine avec Exit 1, indiquant une sortie anormale.

$Assembly = [System.Reflection.Assembly]::LoadWithPartialName("System.Data.OracleClient")

if ( $Assembly ) {
    Write-Host "System.Data.OracleClient Loaded!"
}
else {
    Write-Host "System.Data.OracleClient could not be loaded! Exiting..."
    Exit 1
}

Configuration de la chaîne de connexion

Ensuite, le script configure une chaîne de connexion à la base de données Oracle. Cette chaîne contient l’identifiant utilisateur, le mot de passe et la source de données, qui sont des éléments cruciaux pour établir une connexion sécurisée.

$OracleConnectionString = "user id=#####;password=#######;data source=######"

Connexion à la base de données Oracle

Avec la chaîne de connexion définie, le script crée un nouvel objet OracleConnection et ouvre la connexion à la base de données.

$OracleConnection = New-Object System.Data.OracleClient.OracleConnection($OracleConnectionString);
$OracleConnection.Open()

Exécution d’une requête SQL

Dans un bloc try, le script prépare une commande SQL pour interroger le nombre d’enregistrements dans une table donnée où la colonne IS_DISABLED est égale à 0.

$OracleSQLQuery = "select count (*) from d_d where IS_DISABLED = 0"

Création et exécution de la commande

Un objet OracleCommand est créé et configuré avec la requête SQL et la connexion à la base de données. La commande est de type texte.

$SelectCommand1 = New-Object System.Data.OracleClient.OracleCommand;
$SelectCommand1.Connection = $OracleConnection
$SelectCommand1.CommandText = $OracleSQLQuery
$SelectCommand1.CommandType = [System.Data.CommandType]::Text

Récupération des résultats

Les résultats de la requête sont chargés dans un objet DataTable en utilisant ExecuteReader sur l’objet commande.

$SelectDataTable = New-Object System.Data.DataTable
$SelectDataTable.Load($SelectCommand1.ExecuteReader())

Gestion des erreurs

Si une erreur survient pendant l’exécution de la requête, le script capture l’exception et affiche un message d’erreur. Cela permet d’identifier facilement les problèmes sans interrompre brusquement le script.

catch {
    Write-Host "Error while retrieving data!"
}

Conclusion

Ce script PowerShell est un outil simple mais puissant pour automatiser la récupération de données d’une base de données Oracle. Il est essentiel de remplacer les marqueurs de position pour l’identifiant utilisateur, le mot de passe et la source de données par des valeurs réelles pour assurer le bon fonctionnement du script. De plus, une gestion des erreurs robuste garantit que le script peut traiter les imprévus de manière élégante et informative.

Cet article Interaction avec une base de données Oracle à l’aide de PowerShell est apparu en premier sur CYBERDEV s.p.r.l..