0
processus de release
SharePoint ne sait pas ce qu'est une release
« On est sur SharePoint, mais il nous faut un vrai contrôle de version et des identifiants de documents uniques. »Une révision est un état avec une signature, pas un nom de fichier.
Cas d'usage · Gestion de projet · Ingénierie
Figez une baseline en un clic, comparez deux baselines élément par élément, et publiez avec les approbations jointes. Koddex gère la gestion de configuration sans tableur à côté.
0
modification possible sur une révision diffusée
1 clic
pour ouvrir la révision suivante
Propriétés des règles de diffusion présentées, pas des résultats mesurés.
À voir en 60 secondes
0
processus de release
« On est sur SharePoint, mais il nous faut un vrai contrôle de version et des identifiants de documents uniques. »Une révision est un état avec une signature, pas un nom de fichier.
0
signatures électroniques
« Il nous faut un contrôle des révisions et des releases, celui qu'un PDM donne. SharePoint ne le donne pas. »L'approbation verrouille l'item et le signe. Le modifier exige une nouvelle révision.
20
clics
« Si c'est compliqué, les gens ne font pas. »Réviser est une action sur l'item, donc c'est effectivement fait.
L'approbation verrouille l'élément : ce qui a été validé reste exactement tel que signé, et la modification suivante ouvre une nouvelle révision au lieu de l'écraser.
Chaque jalon de revue est une baseline, et la comparer à la précédente montre ce qui a changé depuis la PDR, élément par élément.
Révisez depuis l'état publié et Koddex garde la filiation, sans renumérotation à la main ni copie de fichier avec un nouveau suffixe.
01
Verrouillez un périmètre à un jalon : son contenu est scellé par une empreinte, et chacun peut vérifier que ce qu'il lit est bien ce qui a été approuvé.
02
L'approbation est enregistrée sur l'élément, avec qui a signé quelle révision.
03
Ouvrez la révision suivante depuis la révision publiée et la filiation est conservée : la configuration à n'importe quelle date passée se retrouve en une requête.
03
Il prend la tâche dans Koddex, travaille sur vos données produit, commente ce qu'il a trouvé et vous remet le résultat à approuver.
AI release engineer
▸List what changed between the PDR and CDR baselines of the gripper.
11 items changed: 4 parts revised, 3 requirements reworded and 4 tests added. 2 of the revised parts are not approved yet, so I moved them to review and notified their approvers.
Chaque action d'agent tracée · limitée aux droits de l'utilisateur
Le périmètre que vous sélectionnez : les entités, leurs valeurs d'attributs et les liens entre elles. Un hash de contenu est inscrit sur ce périmètre : toute différence ultérieure est détectable et non plus une affaire de confiance.
Oui. Le verrouillage crée un point de référence immuable ; le travail continue sur la révision suivante. L'état gelé reste lisible et traversable à côté de l'état vivant.
Non. Koddex se place à côté de votre CAO, de votre PLM et de votre ERP, pas à leur place. Il relie ce qui existe déjà sur un seul graphe, calcule les effets d'une modification et se connecte aux plateformes PLM, QMS, ERP et MES par son API.
Le premier cas d'usage est généralement en production sous 48 heures, et l'onboarding complet prend environ trois semaines, piloté par un Customer Success Manager dédié.
Exclusivement dans l'Union européenne, dans la région AWS Europe (Irlande). Aucune donnée client ne quitte l'Espace économique européen sans votre accord écrit préalable.
Apportez la version qui a demandé une semaine à assembler. Pendant la démo, nous figeons, comparons et révisons une version comme la vôtre dans Koddex.
0-5 min
vous décrivez le produit et la modification
5-15 min
nous montrons le cas d'usage dans Koddex sur un produit comme le vôtre
15-20 min
vous repartez avec un plan pour votre premier cas d'usage, en service en un mois