Plateforme d'ingénierie

Une même chaîne de livraison, du commit à la production.

Les projets présentés dans nos réalisations partagent les mêmes pratiques. Elles ne dépendent pas du langage : Java, TypeScript ou Python passent par les mêmes contrôles et le même mode de déploiement.

Une infrastructure hybride, opérée en production

Les applications clientes et l'inférence IA tournent sur notre propre cluster Kubernetes. Des API dédiées tournent sur un serveur séparé. Chez les clients qui ont déjà un cloud public, l'intégration se fait en Terraform.

Architecture d'infrastructure TDKSOFTLes visiteurs arrivent en HTTPS sur l'Ingress NGINX d'un cluster Kubernetes chez 1blu, qui sert les applications web, PostgreSQL (CloudNativePG), l'inférence d'un LLM auto-hébergé, Argo CD et la supervision. Les applications appellent en HTTPS des API hébergées sur un VPS Hetzner. Le code part de GitHub, passe par la CI et le registre d'images, puis Argo CD synchronise le cluster. Les intégrations sur AWS, GCP ou Azure sont provisionnées en Terraform selon le client.VisiteursHTTPSCluster Kubernetes — 1bluApplications clientesIngress NGINXTLS · cert-managerApplications websites et back-offices clientsPostgreSQLCloudNativePGArgo CDGitOps, sync après revueSupervisionPrometheus · Grafana · LokiSecrets chiffrésSOPS · Kubernetes SecretsLLM auto-hébergéllama.cpp · quotaskubeadm · 2 nœuds · CalicoVPS — HetznerServices APIServices APIconsommés par les applicationsCloud du clientSelon la missionAWSGCPAzureTerraformintégrations en Infrastructure as CodeGitHubPR et revueCI et gatesJenkins · GitHub ActionsRegistreimages versionnées SemVerChaîne de livraisonHTTPS : APIsyncimages
Vue simplifiée : aucune adresse ni aucun nom d'hôte n'est publié.
  • Cluster Kubernetes chez 1blu : installé avec kubeadm, réseau Calico, deux nœuds ; il héberge les sites et applications des clients.
  • LLM auto-hébergé dans le cluster : llama.cpp derrière une passerelle avec quotas par client, utilisé par les assistants conversationnels des sites.
  • VPS Hetzner séparé : services API consommés par les applications du cluster.
  • Clouds publics des clients (AWS, GCP, Azure) : intégrations provisionnées en Terraform, selon l'environnement existant de chaque client.
  • Production pilotée par Git : Argo CD synchronise le cluster, aucune commande de déploiement manuelle.
Chaîne de livraison : Commit et PR → CI et gates → Image versionnée → Promotion GitOps → Argo CD → ProductionCommit et PRCI et gatesImage versionnéePromotion GitOpsArgo CDProduction
Chaîne de livraison

Intégration continue avec gates

Une PR n'arrive sur la branche principale qu'après avoir passé les contrôles.

  • Lint, typecheck, tests et build sur chaque PR (Jenkins ou GitHub Actions selon le projet).
  • Scan de secrets, analyse des dépendances et analyse statique ; SBOM et scan d'image sur les projets les plus exigeants.
  • Contrats d'API (OpenAPI, contrats HTTP) vérifiés en CI pour éviter les ruptures silencieuses.

Conteneurs et Helm

Chaque application est livrée sous forme d'image de conteneur et décrite par un chart Helm ou des manifestes Kustomize versionnés.

  • Builds Docker multi-étapes, images publiées par version.
  • Chart Helm générique alimenté par un profil par application, rendu puis validé avant tout commit.

GitOps avec Argo CD

L'état de la production est celui de Git. Aucun déploiement manuel en production.

  • Promotion d'une version = une modification revue dans un dépôt GitOps.
  • Argo CD compare, puis synchronise après revue du diff.
  • Les commandes de déploiement direct sont bloquées dans l'outillage.

Versionnage SemVer

Tag Git, images de conteneur, version du chart et version applicative restent alignés.

  • Un contrôle CI vérifie l'alignement des versions.
  • Les tags publiés ne sont jamais déplacés ni supprimés.

Gestion des secrets

Aucun secret en clair dans Git ni dans les journaux.

  • Secrets chiffrés avec SOPS et age dans les dépôts d'infrastructure.
  • Toute exposition accidentelle d'un secret entraîne sa rotation, sans exception.

Gouvernance d'ingénierie assistée par IA

Les agents de développement travaillent dans un cadre écrit, revu comme du code.

  • Contrats d'ingénierie (AGENTS.md) réutilisés d'un dépôt à l'autre.
  • Décisions d'architecture (ADR) et livraison par phases avec validation humaine à chaque étape.
  • Un état de reprise vérifié en fin de session, pour que chaque reprise parte de faits et non de suppositions.
Voir ces pratiques dans les études de cas →