kForge — Forge logicielle et intégration continue multi-client

Le problème

Les forges et les moteurs d'intégration continue du marché sont conçus pour une seule organisation. Le jour où vous en servez plusieurs — parce que vous êtes une société de services, parce que vous avez des filiales, parce que chaque entité doit être étanche — vous ne configurez pas un client de plus, vous installez une plateforme de plus.

• Douze clients, c'est douze abonnements, douze consoles d'administration, douze montées de version à planifier, et douze fois la même question posée par votre équipe d'exploitation.
• À côté de la forge, il y a presque toujours un moteur d'intégration continue facturé à la minute ou au siège, et un outil d'analyse de code avec sa propre licence et son propre modèle d'utilisateurs.
• Puis un tableur, ou un abonnement de plus, pour produire les métriques de déploiement qu'on présente au comité de direction.
• Et un outil de suivi de tickets qui ignore les commits, avec des commits qui ignorent les tickets.
• Quatre produits, quatre notions d'utilisateur, quatre journaux — et personne qui puisse répondre simplement à « qu'est-ce que cette mise en production a livré, exactement ? »

Ce que kForge fait

Les quatre produits réunis dans une seule application, avec un seul modèle de client et une seule installation. Vos dépôts restent où ils sont : kForge les agrège, exécute vos pipelines, analyse votre code, et calcule vos métriques sur ce qu'il a réellement déployé.

Vos dépôts, quelle que soit la forge

Un projet agrège des dépôts GitHub, GitLab et locaux — y compris des dépôts nus sur vos propres serveurs, que la plupart des outils ignorent purement et simplement. Historique, branches, étiquettes, différences, blame, recherche plein texte dans les commits, et comparaison de références entre plusieurs dépôts d'un même projet. Les demandes de fusion et les tickets des forges sont répliqués et consultables sans changer d'onglet.

• Suivi des changements : surveillance du répertoire par l’agent pour un dépôt local, scrutation et webhooks signés (GitHub, GitLab) pour un dépôt distant.
• Un ticket peut remonter au tenant parent — d'un client vers le tenant qui le sert, par exemple — si ce parent autorise les remontées ; les tenants qui le suivent sont prévenus de ses changements d'état.
• Les tickets d'une forge deviennent des tickets kForge, avec leurs étiquettes et leur historique.
• Un commit se relie à un ticket, et le ticket montre les commits qui l’ont résolu.

Une intégration continue qui n’invente rien

Étapes, tâches en graphe de dépendances, matrices, exécution en shell, conteneur, Kubernetes ou SSH. Neuf types de déclencheurs, dont l'exécution périodique d'un script en bac à sable et l'interrogation d'une URL dont l'état survit à un redémarrage.

• Douze portes de qualité bloquent une mise en production sur la couverture de test, la latence mesurée, les constats de sécurité ou une régression face à une référence.
• Vos pipelines s'importent et s'exportent en YAML — et s'exportent aussi au format GitHub Actions. La réversibilité est prévue d'emblée.
• Le graphe de dépendances d'une exécution est dessiné sur sa page, avec l'ordre réel dans lequel les tâches ont tourné.
• kForge n'a ni son propre ordonnanceur, ni son propre exécuteur, ni son propre entrepôt d'artefacts : il compile vos pipelines vers le socle Kore, qui les exécute.

L’analyse de code, avec son cycle de vie

28 analyseurs intégrés, plus les vôtres, regroupés en profils. Un constat n'est pas une ligne de journal : il a une empreinte, il se masque ou se supprime durablement — l'exclusion survit aux exécutions suivantes — et sa correction se prouve d'une exécution à l'autre. Un constat devient un ticket ou un risque en un geste, sans doublon.

• Un outil de tri, pas un compteur : la valeur réside dans le tri des constats, et c'est là que porte l'effort.
• Nous ne vendons pas l'analyse statique comme un détecteur de vulnérabilités. Un constat statique est une hypothèse — le moteur voit le point d'arrivée, jamais la garde posée juste au-dessus. C'est pourquoi le produit outille la vérification plutôt que le volume.

Les métriques que vous présentez au comité

Fréquence de déploiement, délai de mise en production, délai de rétablissement, taux d'échec des changements — calculés sur vos exécutions réelles, avec classement automatique par niveau de performance.

• Et surtout, comptés sur les deux chemins : les déploiements lancés par un pipeline ET ceux lancés en ligne de commande.
• Une métrique qui ne verrait que la moitié de la réalité serait pire qu'aucune métrique — parce qu'elle aurait l'air crédible.
• Une page de graphiques composables suit dans le temps les exécutions de pipelines et les déploiements, à partir de modèles prêts à ajouter.

Une IA qui travaille sur votre code sans accès à une machine

La plupart des assistants de développement supposent deux choses : un accès en ligne de commande, et une machine sur laquelle travailler. Pour beaucoup d'organisations, c'est précisément ce qui rend l'IA inacceptable — et la question est vite tranchée. kForge fait un autre choix : l'application expose 63 outils à un agent, regroupés en cinq profils métier, servis par sa propre API.

Aucun de ces cinq profils n'accorde de shell ni d'accès au système de fichiers. Il n'y a donc pas de machine à désigner, pas de répertoire de travail à ouvrir, pas de compte système à créer. L'agent voit ce que l'API expose, sous l'identité de la personne qui le pilote, et rien d'autre. Conséquence : l'assistant devient utilisable en production, et pas seulement sur un poste de développement.

Ce que kForge change

Pour qui

Questions fréquentes