Connectez votre code : modifiez, vérifiez, approuvez, déployez et annulez une vraie base de code

Donnez un nom au projet, puis collez l'adresse du dépôt (à partir du bouton vert Code de GitHub) et la branche depuis laquelle le site fonctionne, en général main. Choisissez comment aiKit y accède. Jeton GitHub : un jeton à granularité fine que vous créez sur GitHub pour ce seul dépôt, avec Contents réglé sur Read and write ; il va avec une adresse https://. Clé de déploiement : une paire de clés créée uniquement pour ce dépôt, dont vous ajoutez la partie publique sous Settings, Deploy keys du dépôt, en cochant Allow write access ; elle va avec une adresse git@. Dépôt public : lecture seule, donc les modifications approuvées n'ont nulle part où être enregistrées ; utilisez-le uniquement pour explorer.

Vous collez vous-même le jeton ou la clé. Ils sont stockés chiffrés sur le moteur d'aiKit et ne sont plus jamais affichés, à personne. La page n'affiche jamais qu'une empreinte. Connecter le dépôt copie le code sur le moteur et détecte le type de projet (Laravel, JavaScript ou fichiers statiques). Rien ne change dans le dépôt.

Un projet que vous avez déjà peut aussi être connecté : dans son onglet Hébergement, le propriétaire voit Connecter votre code.

Votre propre serveur : le site reste exactement là où il est. Saisissez l'adresse du serveur, le port SSH (en général 22), l'identifiant utilisé par aiKit (les étapes de configuration en créent un nommé aikit), le dossier du site (pour un site Laravel Forge, /home/forge/votre-site.com), la commande de déploiement déjà utilisée par le site (en général bash scripts/deploy.sh), et les pages qui doivent répondre après chaque déploiement, une adresse complète par ligne. Collez la clé privée de l'identifiant du serveur (créée à l'étape 1 de la configuration). Enregistrez et vérifiez la connexion.

La première fois qu'aiKit atteint le serveur, il affiche l'empreinte du serveur et demande : Est-ce votre serveur ? Comparez-la avec ce que le serveur a affiché à l'étape 6 de la configuration. N'appuyez sur Correspond que si elles sont identiques, puis sur Connecter. Ensuite, un serveur différent à cette adresse sera refusé. Lorsque la vérification réussit, la page indique la version actuellement en service sur le serveur.

Hébergement aiKit : aiKit construit et sert lui-même le code, avec une adresse gratuite pour commencer. Idéal pour les sites et les interfaces.

Sous Configuration du serveur, la page liste huit étapes à copier-coller, déjà remplies avec vos valeurs ; chacune a un bouton Copier. Les étapes 1 et 8 s'exécutent sur votre ordinateur, les étapes 2 à 7 sur le serveur, avec un utilisateur disposant de sudo.

Ce qu'elles créent : un identifiant sans mot de passe et sans shell (étape 2). Sa clé unique est verrouillée sur un petit script-passerelle (étapes 3 et 5) qui n'accepte que deux commandes : status (quelle version tourne et si le site est en maintenance) et deploy d'un commit précis. Deploy s'exécute avec l'utilisateur propre au site, via une seule règle sudo, vérifie que la branche sur GitHub pointe vers ce commit exact, puis lance votre script de déploiement existant, sans modification. L'étape 4 règle les permissions du dossier pour que l'identifiant n'atteigne que le dossier du site : pas les autres sites du même dossier personnel, et jamais .env. L'étape 7 teste l'ensemble et indique le résultat attendu pour chaque ligne, et l'étape 8 teste l'identifiant depuis votre ordinateur avant que vous ne collIez sa clé dans aiKit.

Si un serveur héberge aussi d'autres entreprises, c'est là que tout se joue : l'identifiant aiKit ne peut déployer que ce site et rien d'autre. Le code du site s'exécute toujours avec l'utilisateur du site, exactement comme lorsque vous déployez vous-même depuis GitHub, ce qui explique pourquoi chaque modification est vérifiée et pourquoi les fichiers sensibles sont protégés.

Quatre tuiles en haut : Dépôt : le dépôt, la branche, le dernier commit et le type de projet. Fonctionne sur : votre propre serveur (avec l'identifiant et la dernière réponse) ou l'hébergement aiKit. Version en ligne : la version en service, son auteur et sa date. Pages : combien de pages devant répondre ont répondu lors de la dernière vérification ; Vérifier maintenant les visite à nouveau, et toute page sans réponse est listée dessous avec ce qu'elle a renvoyé.

Sous les tuiles : Demander une modification (ou la modification en cours), Versions, Journal des modifications, Fichiers protégés et, pour le propriétaire, Connexion.

Décrivez ce qui doit changer, en nommant la page et ce que vous voulez voir, puis appuyez sur Faire la modification. La carte devient Modification n° 1 avec une progression en direct : récupération du dernier code, fichiers lus et modifiés par l'IA, puis chaque vérification. L'IA modifie uniquement les fichiers ; elle n'exécute aucune commande. Une seule modification est ouverte à la fois par projet, et chaque demande compte dans la limite d'IA du projet.

Une fois terminé, vous voyez : la demande et son auteur ; ce que l'IA dit avoir fait ; les vérifications, chacune avec une coche ou une croix et sa sortie ; des boutons Aperçu pour les pages vérifiées ; les fichiers avec Ajouté, Modifié ou Supprimé, et un badge Protégé le cas échéant ; et les différences, fichier par fichier, en vert pour les lignes ajoutées et en rouge pour les lignes supprimées. Ces différences sont exactement ce qui sera enregistré et déployé.

Approuver et déployer (propriétaires et créateurs) enregistre la modification sur la branche avec un message indiquant qui l'a demandée et qui l'a approuvée, l'envoie (jamais en forçant : si quelqu'un a poussé entre-temps, la modification est marquée Obsolète et rien n'est déployé), la déploie et vérifie les pages. Abandonner supprime la modification après une confirmation ; rien n'a été déployé. Les relecteurs peuvent tout consulter mais n'appuient sur aucun des deux boutons.

Après la réussite des vérifications, c'est un paramètre sous Connexion, Vérifications et relecture. Attendre l'approbation est la valeur par défaut. Déployer automatiquement ne déploie seule une modification que si toutes les vérifications ont réussi et qu'aucun fichier protégé n'a changé ; dans les autres cas, elle attend toujours.

Pour un projet Laravel, les vérifications sont les suivantes : chaque fichier PHP modifié est analysé (php -l) ; chaque vue Blade est compilée (php artisan view:cache) ; le front-end est compilé (npm run build) ; et l'application démarre lors d'un test avec une base SQLite jetable, migrée et remplie à partir du dépôt, où chaque page listée dans Pages doit répondre 200. Elles s'exécutent sur le moteur d'aiKit, jamais sur votre serveur et jamais sur votre base de données en production. Le fichier .env du projet n'est jamais copié ni lu ; le test utilise des paramètres jetables.

Une vérification échouée bloque Approuver. Seul le propriétaire peut cocher Déployer malgré l'échec d'une vérification, lorsque celle-ci a échoué pour une raison qui n'affecte pas le site en production.

Aperçu ouvre l'application modifiée issue du test dans un nouvel onglet, avec des données de test et les formulaires désactivés. Il s'arrête 15 minutes après sa dernière utilisation et se termine lorsque la modification est approuvée ou abandonnée.

L'IA ne touche pas aux fichiers protégés. La liste comprend d'abord : les migrations déjà exécutées sur le site en production (toutes les migrations de la version en production, car chaque déploiement les exécute), les nouvelles migrations (elles modifieraient la base de production au prochain déploiement), le script de déploiement, et les fichiers de dépendances (composer.json, composer.lock, package.json, package-lock.json). Chaque entrée indique la raison. Le propriétaire ajoute un fichier ou un dossier (config/** signifie tout ce qui se trouve dans config) avec une raison, supprime des entrées, et appuie sur Enregistrer les fichiers protégés.

Pour modifier volontairement un fichier protégé, le propriétaire coche Autoriser les fichiers protégés pour cette demande. La modification affiche alors les fichiers protégés qu'elle touche, et seul le propriétaire peut l'approuver, après avoir coché Oui, déployer les modifications des fichiers protégés. Un créateur qui ne coche rien n'a aucun accès aux fichiers protégés.

Les fichiers .env, les clés privées et auth.json relèvent d'un niveau plus strict : jamais lus, jamais modifiés, jamais inclus dans un diff, et personne ne peut désactiver cette règle.

La première fois qu'aiKit atteint votre serveur, il enregistre ce que le serveur exécute comme version 1, Avant aiKit, afin que même le premier déploiement d'aiKit puisse être annulé. Ensuite, chaque déploiement est une version numérotée : Modification (une modification approuvée ; son nom ouvre cette modification), Redéployer ou Restaurer, avec son commit, la personne qui l'a effectué, son statut (En ligne, Précédente, En ligne mais pages en erreur, Échec du déploiement), le nombre de pages ayant répondu et le journal de déploiement. aiKit conserve les 5 dernières.

Déployer le dernier code déploie ce qui est le plus récent sur la branche à cet instant, après une confirmation, par exemple lorsque quelqu'un a poussé une correction directement.

Restaurer cette version, sur une version antérieure, crée un nouveau commit dont les fichiers sont exactement ceux de cette version, l'envoie et le déploie de la manière habituelle, puis vérifie les pages. L'historique n'est jamais réécrit, donc la restauration elle-même peut être annulée.

Chaque demande avec son numéro, la demande elle-même, la personne qui l'a faite, celle qui l'a approuvée ou abandonnée, la date et son état actuel. Appuyez sur une ligne pour ouvrir cette modification avec ses vérifications et son diff ; l'adresse reçoit ?change=<id>, vous pouvez ainsi partager le lien avec votre équipe.