Comme le faisait déjà remarquer Roger Cuppens (voir Cuppens, De Cabri I à Cabri- II : quelques problèmes épistémologiques et didactiques, Université d'été " Cabri-géomètre ", Grenoble, 1996), Cabri II vérifie les propriétés sur le dessin montré à l'écran et non sur la figure définie par l'utilisateur, ce qui n'est pas sans poser de sérieux problèmes pédagogiques. Ce comportement est illustré par l'exemple suivant, où l'on constate que l'incidence d'un point et d'une droite dépend du dessin et non de la figure.
De plus, nous avons constaté que la vérification de propriétés par Cabri n'est pas toujours exempte d'erreurs, comme le montre l'exemple suivant, portant sur la propriété d'orthogonalité.
En fait, si vous demandez à Cabri de vérifier si un rayon du cercle inscrit dans un triangle passant par un des points de contact est perpendiculaire au côté contenant ce point de contact, la réponse dépendra de la version de Cabri utilisée : Cabri-Macintosh jugera (incorrectement) la propriété fausse, tandis que Cabri-Java la déclarera vraie.
Avant de tenter d'expliquer ce phénomène navrant, regardons le bon côté des choses. Aux yeux de Cabri, les points de contact entre le cercle inscrit et le triangle existent. Mais, en gardant en mémoire le fait que Cabri effectue ces calculs en se servant d'approximations décimales, on aurait pu s'attendre à ce que le calcul des points d'intersection d'un côté du triangle et du cercle inscrit à ce triangle ne donne pas toujours le résultat escompté. En effet, ce calcul se ramène à la résolution d'une équation de degré deux dont le discriminant est nul. Mais, comme tous les calculs sont approximatifs, il faut s'attendre à ce que de petites erreurs interviennent dans le calcul du discriminant, et en particulier il faut prévoir que le discriminant en question soit parfois négatif, entraînant la non-existence du point de contact correspondant.
Or ceci n'arrive jamais, du moins dans les cas que nous avons obtenus. Comment expliquer ce comportement de Cabri? Une stratégie "informatique" possible (utilisée dans ProEuclide) est de rendre nuls tous les " petits " discriminants. Tout l'art réside alors dans le choix du seuil en dessous duquel un discriminant est considéré "petit".
Revenons à la vérification de l'orthogonalité : une façon de faire est de vérifier si le produit scalaire des vecteurs en question (préalablement normalisés) est nul. Mais, comme tous les calculs sont approximatifs, on ne peut en fait qu'exiger que de tels produits scalaires soient "petits". Il nous faut ici rechercher un équilibre entre une trop grande exigence (qui nous conduirait à déclarer non perpendiculaires des segments orthogonaux) et une trop grande permissivité (qui nous amènerait à déclarer orthogonaux des segments qui ne le sont pas). Comme on l'a vu, cet ajustement semble mieux réussi dans Cabri-Java que dans Cabri-Macintosh.
Une autre stratégie (utilisée dans Cabri I et
dans ProEuclide) est de chercher à vérifier la propriété
pour la figure et non pour le seul dessin. On conçoit alors
qu'il faille vérifier la propriété (peut-être
avec une exigence moins grande) sur plusieurs cas particuliers
de la figure à l'étude. Dans ProEuclide, quand on demande de vérifier
une propriété, le logiciel affiche explicitement
tous les cas qu'il a considéré pour vérifier
la propriété en question.