Rapports d’informatique et détection de l’IA : le code, le pseudocode et la prose entre les deux

La position publiée de Turnitin sur le code est courte et précise : le modèle « does not reliably detect AI-generated text in the form of non-prose, or code » (ne détecte pas de façon fiable le texte généré par IA sous forme de non-prose ou de code), et la FAQ ajoute que Turnitin est « not pursuing ChatGPT code detection at this time. » (ne cherche pas, à ce stade, à détecter le code produit par ChatGPT). Vos listages, vos blocs de pseudocode et vos transcriptions de terminal ne sont donc pas ce que mesure le pourcentage d’IA. Ce sont les paragraphes entre les deux, ce qui, dans un rapport d’informatique, signifie la justification de la conception, le parcours de l’algorithme, l’analyse de complexité et la discussion de l’évaluation. Ces paragraphes sont aussi l’écriture la plus uniforme du document, parce qu’un bon texte technique est censé être uniforme.

Indépendamment de tout cela : ce que votre département vous autorise à produire est fixé par sa politique d’intégrité académique, pas par ce qu’un détecteur mesure. Répondre à l’une de ces questions ne répond pas à l’autre, et les traiter comme une seule et même question, c’est ainsi qu’on finit par se retrouver en réunion.

Deux phrases portent tout le sujet. La première se trouve dans la définition que donne la FAQ de ce qui est analysé :

"The model does not reliably detect AI-generated text in the form of non-prose, or code, nor does it detect short-form/unconventional writing such as bullet points (short non-sentence structures)." (Le modèle ne détecte pas de façon fiable le texte généré par IA sous forme de non-prose ou de code, et il ne détecte pas non plus l’écriture courte ou non conventionnelle, comme les listes à puces, c’est-à-dire de courtes structures qui ne sont pas des phrases.)

Lisez une ligne de plus, car c’est là que cela devient utile :

"This means that a document containing several different writing types would result in a disparity between the percentage and the highlights." (Cela signifie qu’un document contenant plusieurs types d’écriture différents produirait un écart entre le pourcentage et les surlignages.)

Un rapport d’informatique est, par construction, un document qui contient plusieurs types d’écriture différents : cet écart est donc l’état normal de ce genre de texte, et non une anomalie. Le guide du rapport énonce la même exclusion avec une liste plus longue : il nomme la poésie et les scripts à côté du code, et ajoute les tableaux et les bibliographies annotées du côté des formes courtes.

La seconde phrase circule généralement sans son contexte, il vaut donc la peine de dire où elle se trouve. C’est la dernière ligne de la réponse à « Why is AI detection not being added to Gradescope? » (Pourquoi la détection de l’IA n’est-elle pas ajoutée à Gradescope ?), et cette réponse indique que Turnitin « not currently have plans to add these capabilities to Gradescope, since the primary use case for Gradescope is handwritten text while for AI detection we're focusing on typed text » (n’a actuellement pas l’intention d’ajouter ces capacités à Gradescope, puisque le cas d’usage principal de Gradescope est le texte manuscrit alors que, pour la détection de l’IA, nous nous concentrons sur le texte tapé au clavier), puis : « In addition, we are not pursuing ChatGPT code detection at this time. » (En outre, nous ne cherchons pas, à ce stade, à détecter le code produit par ChatGPT).

Cela compte plus en informatique que dans n’importe quelle autre discipline, parce que Gradescope est l’endroit où une grande partie des travaux de programmation est rendue. Si votre implémentation part vers un correcteur automatique et que votre rapport écrit part vers un devoir Turnitin, ce sont deux circuits qui ont des rôles différents, et le pourcentage d’écriture IA que vous voyez au final a été calculé sur le second. Quel produit Turnitin dispose de la détection de l’IA traite du volet licence de cette séparation.

La définition figure dans le guide du rapport, et ses exemples méritent attention :

"Qualifying text (prose sentences contained in long-form writing format) means individual sentences contained in paragraphs that make up a longer piece of written work, such as an essay, a dissertation, or an article, etc." (On entend par texte éligible — phrases de prose contenues dans un format d’écriture long — les phrases individuelles contenues dans les paragraphes qui composent un travail écrit plus long, comme un essai, une thèse ou un article, etc.)

Un essai, une thèse, un article. Un rapport de projet écrit dans le registre d’une documentation d’API n’est aucune de ces trois choses, et Turnitin ne publie aucune décision à ce sujet. Ce qu’il publie, c’est le test de la phrase ; voici donc ce test appliqué élément par élément. C’est notre classification, pas celle de l’éditeur.

Deux conséquences découlent de ce tableau. Votre dénominateur est petit : le pourcentage est donc une affirmation sur une tranche du fichier et non sur le fichier, ce que la FAQ dit en toutes lettres : "This percentage is not necessarily the percentage of the entire submission. If text within the submission is not considered long-form prose text, it will not be included." (Ce pourcentage n’est pas nécessairement celui de l’ensemble de la soumission. Si un texte de la soumission n’est pas considéré comme de la prose longue, il ne sera pas inclus.) Et si le rapport est chargé de listages, il peut rester si peu de texte éligible que le comportement du tout ou rien des documents courts devient pertinent. Les exigences de fichier indiquent qu’une soumission doit comporter "at least 300 words of prose text in a long-form writing format" (au moins 300 mots de prose dans un format d’écriture long) pour qu’un rapport soit produit.

Turnitin publie une description de ce que ses faux positifs ont tendance à avoir en commun :

"Sometimes false positives (incorrectly flagging human-written text as AI-generated), can include content without a lot of structural variation, text that literally repeats itself, or text that has been paraphrased without developing new ideas." (Il arrive que les faux positifs, c’est-à-dire le fait de signaler à tort comme généré par IA un texte écrit par un humain, concernent un contenu avec peu de variation structurelle, un texte qui se répète littéralement, ou un texte paraphrasé sans développer d’idées nouvelles.)

Et la phrase suivante, qui s’adresse à la personne qui vous évalue plutôt qu’à vous :

"If our indicator shows a higher amount of AI writing in such text, we advise you to take that into consideration when looking at the percentage indicated." (Si notre indicateur montre une quantité plus élevée d’écriture IA dans un tel texte, nous vous conseillons d’en tenir compte en regardant le pourcentage indiqué.)

Lisez maintenant ces deux propriétés à l’aune d’un document technique bien écrit. La variation structurelle est précisément ce qu’une section de référence supprime délibérément : chaque fonction reçoit le même cadre, d’abord le nom, puis les paramètres, puis la valeur de retour, puis les modes de défaillance, pour qu’une personne qui a appris le cadre une fois puisse survoler le reste. Dire la même chose deux fois de la même façon, c’est exactement ainsi que vous indiquez à un lecteur que deux composants se comportent de la même manière. Un guide de style qui vous dirait de varier la forme de chaque entrée serait un mauvais guide de style.

La même forme apparaît dans le parcours de l’algorithme, pour une autre raison. Cette section réénonce généralement en mots ce que le listage placé au-dessus dit déjà. Réénoncer quelque chose n’a nulle part où aller sur le plan stylistique. Chaque étape commence par l’étape, chaque phrase a le même sujet, et le paragraphe est une transcription du flux de contrôle.

Deux limites honnêtes à cela. Turnitin ne donne aucune fréquence pour ces propriétés, seulement une liste de ce que les faux positifs « can include » (peuvent inclure) : personne ne peut donc vous dire quelle part de l’effet cela explique. Et le comportement du modèle n’est pas un règlement à partir duquel vous pouvez raisonner à rebours : la FAQ indique que "Our model is not explicitly programmed to evaluate specific signals such as 'burstiness,' 'perplexity,' or other individual metrics sometimes referenced in public discussions." (Notre modèle n’est pas explicitement programmé pour évaluer des signaux spécifiques comme 'burstiness,' 'perplexity,' ou d’autres mesures individuelles parfois évoquées dans les débats publics.) Le mythe de perplexity et burstiness donne la version complète, y compris la phrase qui figure ailleurs sur la même page et qui vous empêche de surinterpréter celle-ci.

Voici l’asymétrie qui distingue les rapports d’informatique des essais. Le contenu exclu de la mesure n’est pas un décor inerte. C’est la partie du document où un seul caractère modifié rend le document faux, et une passe de révision la lit, que quelqu’un la note ou non.

Il existe un second échec, plus difficile à voir, parce que le résultat se lit parfaitement bien. Un document technique donne un seul nom à un seul concept. Si une révision laisse `hash map` dans la section 3 et `dictionary` dans la section 4 pour le même objet, ou alterne entre `worker` et `thread`, le document ne dit plus au lecteur s’il s’agit d’une chose ou de deux, et la personne qui évalue ne peut pas trancher sans lire votre code. C’est un dommage causé au document, et là non plus aucun score n’entre en jeu. Cela vaut la peine de le dire, parce que cela va contre une habitude qui vous sert partout ailleurs : dans la plupart des écrits, un terme défini est un choix de mots, et dans ce genre de document, il est plus proche d’un identifiant.

Aucune de ces vérifications n’exige un outil que vous n’auriez pas déjà ouvert.

• Copiez toutes les commandes du document et exécutez-les dans un répertoire jetable. Les instructions d’installation sont ce qui se périme en premier et ce que personne ne relit jamais.
• Listez les identifiants que définit votre code et cherchez chacun d’eux dans le document. Tout ce qui figure dans le code et manque dans le document est un renommage qui a eu lieu sans vous.
• Choisissez vos cinq termes conceptuels les plus importants et cherchez chacun. Un seul nom par concept, partout, ou corrigez-le maintenant.
• Relisez chaque affirmation de complexité à l’aune de la fonction qu’elle décrit. `O(n log n)` et « efficace » ne sont pas interchangeables, et une seule des deux est notifiable.
• Confrontez tout ce qui est entre guillemets à une exécution réelle. Les lignes de journal et les messages d’erreur sont des citations.

Si le bloc signalé est votre parcours d’algorithme, il y a une question à vous poser avant de toucher aux phrases : cette section fait-elle quelque chose que le listage placé au-dessus ne fait pas déjà ? Un parcours qui se contente de renommer les variables et d’ajouter « ensuite » entre les étapes est un contenu en double dans un rapport, quoi qu’en dise un détecteur. La version qui mérite sa place explique pourquoi la boucle est structurée ainsi, quelle était l’alternative, et où elle s’effondre.

C’est aussi là que votre écriture a quelque part où aller. Justification de la conception, alternatives écartées, le bogue qui vous a coûté deux jours, ce que le banc d’essai ne mesure pas, la limite que vous corrigeriez avec une semaine de plus. Ces paragraphes varient dans leur forme parce que la pensée qu’ils contiennent varie. Les sections de style référence ne varient pas, et ne doivent pas varier.

Il vaut mieux être honnête sur les limites de ce conseil : je décris ce qui rend un rapport plus agréable à lire et plus facile à évaluer. Personne, nous y compris, ne peut vous dire ce que cela fait à un chiffre. Turnitin ne publie ni la fonction de regroupement ni la longueur des segments, et il prévient que son propre modèle "may not always be accurate (it may misidentify human-written, AI-generated, and AI-paraphrased text), so it should not be used as the sole basis for adverse actions against a student." (n’est pas toujours exact, qu’il peut mal identifier un texte écrit par un humain, généré par IA ou paraphrasé par IA, et qu’il ne doit donc pas servir de seule base à des mesures défavorables à un étudiant).

Ce qui rend un rapport d’informatique lent à réviser a peu à voir avec les phrases. Un paragraphe réécrit peut porter quatre identifiants, un drapeau et un numéro de version, et chacun d’eux doit être revérifié contre le code avant que vous puissiez faire confiance au paragraphe. Comptez le coût en paragraphes touchés.

C’est pourquoi L’outil HumanPen vous demande de nommer d’abord le périmètre. Téléversez le document, puis marquez les passages ou importez un rapport d’IA Turnitin ou iThenticate et laissez ses passages signalés tracer la frontière. Tout ce qui se trouve à l’extérieur reste intact, ce qui, dans ce genre de document, signifie que vos listages et vos blocs de commandes ne sont pas du tout dans la passe, sauf si vous les y mettez. Le moteur ne descend pas en dessous du paragraphe : une sélection qui s’arrête au milieu d’un paragraphe est donc élargie pour couvrir le paragraphe entier et vous est d’abord présentée pour confirmation, et les crédits comptent les mots réellement réécrits. La terminologie figure dans la liste des éléments qu’il cherche à préserver, à côté de la structure, des citations et de la mise en page. Les passages encore signalés ensuite peuvent être réécrits à nouveau gratuitement lorsque les conditions en sont réunies.

Il y a une ligne dans sa FAQ sur la relecture des documents complexes après téléchargement. Pour un rapport rempli d’identifiants, cela signifie la liste de contrôle de la section précédente, et non une lecture continue. La version au niveau du document de ce qui casse lors d’un aller-retour, champs et références croisées compris, se trouve dans Champs Word, tables des matières et références croisées.

Turnitin détecte-t-il le code généré par IA ? Turnitin indique que son modèle ne détecte pas de façon fiable le texte généré par IA sous forme de non-prose ou de code, et la FAQ indique qu’il ne cherche pas, à ce stade, à détecter le code produit par ChatGPT. C’est une affirmation sur ce que ce rapport mesure. Ce n’est pas une affirmation sur ce que votre établissement autorise, ce qui est un document distinct que vous devriez lire.

Mon bloc de pseudocode est-il noté ? La règle publiée est que le modèle analyse les phrases de prose à l’intérieur des paragraphes, et il cite les formes courtes et les structures qui ne sont pas des phrases parmi ce qu’il ne détecte pas. Un bloc de pseudocode est structuré en lignes, et non en phrases. Le paragraphe qui le présente, lui, est de la prose.

Pourquoi les surlignages sont-ils si concentrés dans une section ? En partie pour une raison arithmétique. Si la majeure partie de votre fichier est exclue, les surlignages ne peuvent apparaître que dans ce qui reste. Turnitin décrit aussi le fait de noter des segments qui se chevauchent et de regrouper les valeurs : les passages de texte uniformes ont donc tendance à produire des résultats uniformes plutôt qu’une dispersion.

Ma section d’analyse de complexité a été signalée alors que j’ai écrit chaque mot. Cela arrive, et le paragraphe de la FAQ sur les faux positifs est ce qu’il faut mettre devant la personne qui évalue, en particulier sa dernière phrase, qui lui conseille de tenir compte de la nature du texte en lisant le pourcentage. Ce qu’il ne fera pas, c’est trancher la question de la paternité du texte, dans un sens comme dans l’autre.

Mon rapport est presque entièrement constitué de listages et aucun rapport d’IA n’a été produit. Vérifiez le plancher avant de supposer que quelque chose a échoué. Les exigences de fichier indiquent qu’une soumission doit comporter au moins 300 mots de prose dans un format d’écriture long, et un rapport chargé de listages peut rester en dessous même quand le nombre de pages paraît correct. La liste générale des exclusions se trouve dans le contenu que l’IA de Turnitin ignore.