kForge

Vos outils de développement ne savent pas compter jusqu’à deux clients

GitHub Enterprise, GitLab Self-Managed, Jenkins, CircleCI : tous excellents, tous construits pour UNE 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 apporte

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 en temps réel des changements, par scrutation et par webhooks signés (GitHub, GitLab).
• 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 deux qu'aucun concurrent ne propose : l'exécution périodique d'un script en bac à sable, et l'interrogation d'une URL avec garantie de non-perte, y compris après 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. Nous livrons le bouton qui permet de partir.
• 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 triage, pas un compteur : c'est le tri qui a de la valeur, et c'est là qu'on a mis le travail.
• 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 IA qui travaille sur votre code sans qu’on lui ouvre 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 le sujet s'arrête là. kForge prend l'autre chemin : 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. Ce que ça change : l'assistant devient utilisable en production, et pas seulement sur un poste de développement.

Trois raisons de choisir kForge

Pour qui

Ce qui vient avec, et ce qui n’y est pas

Un discours de vente qui ne dit pas ses limites vous les fera découvrir au deuxième mois. Voici les nôtres, maintenant.