serard@dev00:~/cv

public class App : IHostedService { private readonly ILogger _log; private readonly IServiceProvider _sp; public async Task StartAsync(CancellationToken ct) { var result = await _sp.GetRequiredService<IPipeline>() .Map(ctx => ctx.Validate()) .Bind(ctx => ctx.Execute()) .Recover(err => Result.Fail(err)); _log.LogInformation("Pipeline: {Status}", result); } } [AggregateRoot("Order")] public partial class OrderAggregate { [Property] public string CustomerId { get; } [Property] public OrderStatus Status { get; } [Composition] public List<OrderLine> Lines { get; } [Invariant] public bool MustHaveLines() => Lines.Count > 0; [DomainEvent] public record OrderPlaced(string OrderId, DateTime At); } const render = async (md: string) => { const { html, meta } = await marked.parse(md); document.querySelector('#output').innerHTML = html; await processMermaid(document.querySelector('#output')); hljs.highlightAll(); }; <template> <nav id="sidebar" role="navigation"> <div v-for="section in toc" :key="section.id"> <a :href="section.path">{{ section.title }}</a> </div> </nav> </template> apiVersion: apps/v1 kind: Deployment metadata: name: api-gateway spec: replicas: 3 selector: matchLabels: app: gateway template: spec: containers: - name: api image: registry.local/api:latest ports: - containerPort: 8080 [MetaConcept("Entity")] public abstract class EntityConcept { [MetaProperty] public string Name { get; } [MetaReference] public AggregateConcept Root { get; } [MetaConstraint] public bool NameNotEmpty() => !string.IsNullOrEmpty(Name); } module.exports = { entry: './src/index.ts', output: { path: path.resolve(__dirname, 'dist') }, resolve: { extensions: ['.ts', '.js'] }, module: { rules: [{ test: /\.ts$/, use: 'ts-loader' }] } };

Note de corroboration technique - QWAPP, software factory et environnements

Date d'analyse: 18 juin 2026

Objet: corroborer, avant toute qualification Syntec, que les pieces PDF montrent bien la definition, la construction et la presentation d'une software factory transverse avec environnements multiples, outillage de developpement, CI/QA, preproduction et mecanismes de deploiement.

Corpus examine

content/blog/si_qwant/SOFTWARE_FACTORY/qwant-dev-ci-qa-prez-cdc.pdf
content/blog/si_qwant/SOFTWARE_FACTORY/Qwapp 2015-08-12 (3).pdf

Exports realises:

output/pdf/qwant-dev-ci-qa-prez-cdc-pages/
output/pdf/qwapp-2015-08-12-3-pages/

Metadonnees probantes

qwant-dev-ci-qa-prez-cdc.pdf
- auteur PDF: Stephane Erard
- date de creation: 31 mai 2016 11:38:24 +02:00
- page 1: le support est presente sous les noms Jean-Charles Chemin et Stephane Erard
Qwapp 2015-08-12 (3).pdf
- auteur PDF: Stephane Erard
- date de creation: 12 aout 2015 11:28:48 +02:00

Conclusion intermediaire: les deux supports ne sont pas de simples captures anonymes. Ils sont attribues a Stephane Erard, et le premier le positionne en plus comme presentateur explicite du dispositif.

Constat 1 - QWAPP est presente comme un outil d'integration interne, pas comme un simple script

Dans Qwapp 2015-08-12 (3).pdf:

page 1: QWAPP est decrit comme un outil d'integration pour les applications Qwant
page 2: QWAPP articule Project, Branch, Env, Config, Computer, Network
page 10: QWAPP expose une CLI structuree en familles de commandes
pages 14 a 30: les commandes sont detaillees une a une
page 31: Qwapp-init initialise un nouveau projet avec un squelette
page 32: Qwapp-clone clone un projet depuis un groupe GitLab

Cela decrit un produit interne de software factory, pas un usage passif d'outils standards.

Constat 2 - Les environnements DEV, CI et de validation sont explicitement modelises

Dans Qwapp 2015-08-12 (3).pdf:

page 3:
- local.config_dev.json used by devs
- local.config_ci.json used on CI infra
- Any new env can be added
- configuration hierarchique et surchargeable
page 4:
- arborescence des environnements dev, ci, everlast, preprod
- articulation avec des dimensions de configuration
page 5:
- generation de configurations pour des matrices d'environnements
- exemples d'environnements dev, ci, everlasting
page 25:
- Qwapp-config-ls sort la configuration pour un --env donne
page 26:
- Qwapp-config-create remplace le script maison generate-config.sh

Dans qwant-dev-ci-qa-prez-cdc.pdf:

page 8:
- chaine DEV -> CI-QA -> CD -> OPS
- Validation via Everlast
page 13:
- commande de release vers prelive

Conclusion intermediaire: les documents montrent noir sur blanc une taxonomie d'environnements, leur configuration et leur usage operationnel. On n'est pas sur un discours vague de "bonnes pratiques".

Constat 3 - Les environnements sont generes, parametres et multiplies automatiquement

Dans Qwapp 2015-08-12 (3).pdf:

page 5:
- QWAPP genere des configurations a partir de dimensions combinatoires
page 6:
- les specifications d'application permettent de faire apparaitre des environnements de test pour chaque combinaison pertinente
- objectif annonce: mise a jour de jobs Jenkins en mode matrice
page 7:
- usage de variables ENV, BRANCH, USER, CIKIND
- generation de config/local.config_$ENV.json
- generation de config/php/local.config_$ENV.json
page 27:
- Qwapp-config-set positionne des valeurs dans les fichiers local.config_env
page 29:
- Qwapp-config-param-ls liste les usages d'un parametre de configuration

Ce point corrobore un vrai travail de modelisation d'environnements, de parametrage et d'automatisation a l'echelle de plusieurs contextes techniques.

Constat 4 - La software factory inclut la plateforme de developpement des developpeurs

Dans Qwapp 2015-08-12 (3).pdf:

page 8:
- Vagrant box for devs
- Using docker in a vagrant
- usage de Puppet pour les dependances
- extension a plusieurs plateformes cibles
page 9:
- deploiement de tous les services d'infrastructure sur des boxes Vagrant
- isolation des developpements, tests et mises a jour
- sans contaminer l'infrastructure CI de production
page 11:
- plateformes de developpement uniformisees
- provisioning out of the box
- versionnement
- serveur DNS fourni par VagrantDev
page 12:
- schema detaille Qwapp Host Computer -> VagrantDev -> Containers / PowerDNS / Puppet / Docker-compose
page 34:
- procedure d'installation sur la machine hote
page 35:
- personnalisation de custom-config.yml
- hostname, DNS server, VM IP, plage IP Docker, etc.

Conclusion intermediaire: le second PDF prouve que l'outil ne sert pas seulement a "builder". Il installe et orchestre le poste de developpement, les dependances, le DNS et les conteneurs utilises par les developpeurs.

Constat 5 - Les conteneurs et le chargement d'environnements sont explicites

Dans Qwapp 2015-08-12 (3).pdf:

page 14:
- Qwapp-compose-up charge un environnement via docker-compose
page 15:
- Qwapp-compose-down arrete l'environnement charge
page 16:
- Qwapp-compose-dns-map gere le mapping DNS de la composition active
page 17:
- Qwapp-compose-dns-unmap
page 18:
- Qwapp-compose-update
pages 19 a 21:
- generation Dockerfile, symlinks, templates
page 22:
- Qwapp-dns-map
page 23:
- Qwapp-dns-unmap
page 24:
- Qwapp-dns-zone-create
page 36:
- les conteneurs sont deployes avec qwapp-compose-up

Cela corrobore l'existence d'une chaine technique complete: config, generation, chargement, resolution DNS et cycle de vie d'environnements conteneurises.

Constat 6 - Le PDF QWAPP prouve directement l'usage pour le front; le premier deck relie QWAPP au reste du SI applicatif

Dans Qwapp 2015-08-12 (3).pdf:

Page	Miniature cliquable	Elements directement visibles
p.33		Exemple d'usage avec `FRONT SEARCH Instance 1`, `FRONT SEARCH Instance 2` et un conteneur `PDNS`.

Dans qwant-dev-ci-qa-prez-cdc.pdf:

Page	Miniature cliquable	Elements directement visibles
p.14		Cartographie avec `Groupe BACK`, `API`, `IA`, `CROPPER`, `Groupe QWAPP (R&D-Dev-Support)`, `VAGRANT`, `DOCKER` et `CONFIG`.
p.15		Architecture `FRONT (SEARCH, BOARDS)`.
p.16		Architecture `FRONT (SEARCH, BOARDS) LITE`.
p.20		Composants utilises sur plusieurs piles: `Node.JS`, `PHP`, `Java`, `Docker`, `Vagrant`, `NEXUS`, `ElasticSearch`, `MongoDB`, etc.

Conclusion intermediaire: le second PDF prouve directement l'outillage du front. Le premier montre que le groupe QWAPP est pense comme support transverse au front, au back/API et aux autres composants applicatifs.

Constat 7 - Correlation forte entre les deux PDFs

Les deux supports se corroborent mutuellement:

le schema Project / Branch / Env / Config / Computer / Network apparait dans les deux presentations
- Qwapp 2015-08-12 (3).pdf, page 2
- qwant-dev-ci-qa-prez-cdc.pdf, page 7
le premier deck montre la vue "software factory / process / CI-QA / release / architecture"
le second deck montre la vue "outil concret / implementation / commandes / provisioning / DNS / conteneurs / config"
Everlast du premier deck correspond a la famille d'environnements everlast ou everlasting du second
prelive du premier deck et preprod du second montrent une chaine de validation/deploiement intermediaire avant exploitation

Autrement dit:

le premier PDF etablit la portee transverse de la factory
le second PDF etablit la realite technique de l'outil et des environnements

Point de precision sur "Everlast / UAT"

Les PDF montrent explicitement:

CI-QA
Validation via Everlast
everlast ou everlasting
preprod
prelive

Pris isolement, les deux PDF n'emploient pas litteralement l'acronyme UAT.

La formulation la plus rigoureuse est donc:

si l'on retient la precision contextuelle suivante, a savoir que chez Qwant l'environnement de validation s'appelait initialement Everlast, alors Everlast doit etre lu comme la denomination historique interne de l'UAT
les pieces prouvent formellement une chaine DEV / CI / QA / Everlast / preprod-prelive
l'absence du sigle UAT dans ces deux PDF releve alors d'une question de vocabulaire historique, pas d'une absence d'environnement de recette/validation
une piece supplementaire employant explicitement UAT ou recette resterait utile pour verrouiller encore davantage l'equivalence terminologique, mais n'est pas necessaire pour constater la fonction technique de validation

Conclusion technique provisoire

Les deux PDFs, pris ensemble, corroborent fortement les points suivants:

existence d'une software factory interne Qwant
existence d'un outil interne nomme QWAPP
definition explicite d'environnements multiples
generation et parametrage des configurations par environnement
outillage de developpement des developpeurs
orchestration Vagrant, Docker, Puppet, DNS et conteneurs
lien direct avec Jenkins, CI, QA, Everlast, c'est-a-dire l'environnement de validation/UAT sous sa denomination historique, et release prelive
support direct du front et support transverse au reste du SI applicatif

La these factuelle soutenable n'est donc pas "simple utilisation d'outils de dev".

La these factuelle soutenable est:

conception et presentation d'un outillage transverse de software factory
modelisation de l'articulation branch / env / config / machine / network
industrialisation des environnements de developpement, de CI et de validation
capacite a brancher la chaine sur le front, les releases et les services applicatifs

Base de travail pour l'etape suivante:

une analyse Syntec 3.3 peut maintenant s'appuyer sur une base technique beaucoup plus solide, parce qu'il ne s'agit plus seulement de slides de process, mais d'un dispositif outille, structure, auteurise et relie a plusieurs services.
prolongement redige: Analyse Syntec 3.3 page par page des PDFs QWAPP et software factory

⬇ Download